[BUG][LEMMIX PLAYERS] Bomber/explosion particles not cleaned up until scroll

[Aaron44126]

Not sure where to post this; I'm posting it in the NeoLemmix bugs forum, but this is not a bug with NeoLemmix; I am experiencing it with the classic Lemmix "players" that can be found on the NeoLemmix web site.  https://www.neolemmix.com/?page=download_list&program=42

The bug is, after having a lemming blow up with the "bomber" skill, the explosion causes guts/particles to fly into the air.  Once the animation is done, the particles are often (usually?) not cleaned up, so a small number of particles remain suspended in the air.  They will be cleaned up once the stage is scrolled, or if there is another explosion.



Not sure if these are maintained anymore; if not then I will take a stab at fixing this myself, since the player source code is available, but I am not sure how I would publish the results.

[Aaron44126]

OK...  I am a software developer by trade, but I've never done any Delphi before.  I did take a look at the source and I found some nice text documentation on how the explosions work and I also located the code in LemGame.pas that handles drawing the explosion particles.  I believe that I could make the appropriate adjustments to fix this bug.  What I need help with is how to actually build the game EXE so that I can test it out.  So if anyone who knows happens across this post in the next 6-8 hours and wants to point me in the right direction, that would be awesome.  Otherwise, I will be digging in on my own this evening, once my regular obligations for the day are done.

Thanks.

[namida]

Those are no longer maintained. Basically - the only Lemmings projects I'm currently working on are NeoLemmix, and (to the bare minimum standard to keep it useable and latest-version-compatible) the associated level editor. I guess theoretically, if a huge bug with L3DEdit came up, I'd probably fix that too, but I'm not likely to do any further general work on it.

EricLang, the original developer of Lemmix, has recently revived his work on it. However, his starting point was his own existing code, not the further additions made by myself and ccexplore, which means some DOS glitches are not accurately replicated by it (and a few that are indisputably present in DOS, but EricLang doesn't personally like, have been relegated to options rather than inherent behaviours). I wouldn't be surprised if he's already dealt with that glitch in his new version, though.

If you did want to look at improving the existing source code, you need Delphi 7 to compile it. The only legitimate way to obtain that these days it to purchase the non-free edition of current version of Delphi and make use of that it comes with a complimentary copy of all older versions; but I'll let you decide how worried you are about "legitimate" when it comes to a nearly-20-year-old piece of software, especially when the current version of it can be obtained legitimately for free but older versions cannot.

It may be more productive to put your efforts into assisting EricLang with his new version though, including replicating the bugs that it currently doesn't replicate accurately / improving it to have 100% replay file compatibility with the versions on NL.com (the bugs that it does replicate that EricLang's code originally didn't, it usually does so in a different way, and thus the replays aren't compatible). I believe he's using the latest version of Delphi - for which a free edition can be obtained - for this.

[Aaron44126]

Thanks.  I, um... found... a copy of Borland Delphi 7 and was able to build LemmixPlayer.exe.  I'll look into fixing the bug a bit later this evening.

[Aaron44126]

Well.  Fought with this enough for one day.  I messed with it for a while and the quickest 100% working fix that I could come up with is this cheesy one which just solves the problem by not drawing the last frame of the "explosion".

I can conclude that the "EraseParticles" function is not (always) cleaning up particles from the last frame.  (At first I thought that it wasn't getting called on the last frame, but I adjusted the logic there to make sure that it is and it still wouldn't do its job.)  Need to understand what it is doing better to find the proper fix.

[Aaron44126]

Eh, came back and worked on it some more.  The logic in EraseParticles seems sound so I'm not sure why they are not all being erased.  The particles disappear when the level is scrolled so it is like the particles are being erased properly, but not all updates to fTargetBitmap are being applied right away?

Anyway, I fixed it by adding an additional frame to the explosion animation data that is just empty.
https://github.com/AaronKelley/LemmixPlayer/commit/c1dcf9ae08c588250124257b6b8b1a0e1d4684b8

Still want to test it (by actually playing the game for a while) and see if it is solid.

I don't know if you would like to publish an updated set of EXE files on the NeoLemmix site, or if I should just publish them on GitHub.
I noticed that the scrolling text at the bottom of the main screen gives a dead URL to some Lemmings forums so I'd also like to update it to point to this site.

[ccexplore]

This change can potentially affect existing solutions (eg. saved replays).  When a lemming explodes, the game waits a specific number of frames before actually removing the lemming from the level.  Depending on how Lemmix is programmed, it's quite likely that when you change PARTICLE_FRAMECOUNT, you are also increasing that number of frames by 1, thereby delaying when the lemming is actually removed.  This in turn can affect the timing of nuking--when player starts nuke, the game starts the countdown lemming by lemming, frame by frame.  If a lemming is in a state where it's not already removed but also not eligible to start a countdown (eg. it is already splatting, already has a countdown due to assigned bomber earlier, or it is already exploding but not yet actually removed, etc.), the game doesn't move on immediately to the next lemming to assign nuke-induced countdown, it still waits for next frame to move on to the next lemming.  As a result, changing how long after an explosion before the lemming is removed from level can, in a suitably arranged situation, slightly affect how soon the next lemming after it gets its nuke-induced explosion countdown started.

It's true that most solutions will not utilize nuking in frame-precise manners so the overall impact will be quite low, but it is still a change that can in principle affect emulation accuracy in a way that impacts viability of level solutions, and therefore not an acceptable fix for any official LemmixPlayer versions.

I'd suggest looking for a different fix that does not require changing PARTICLE_FRAMECOUNT etc.  In fact, given what I said above, I'd venture a guess that maybe the bug is a side effect of the lemming also getting removed right at the end of completing all its frames for the explosion particles.  Perhaps the lemming got marked as removed, and as a direct side effect then the work needed to make the final rendering happen right away (ie. without requiring scrolling the level) was unintendedly skipped, leading to the effect you observe.

[Aaron44126]

I thought about this.  It looks like the Lemming is removed immediately, right when the particle framecount begins counting, and the framecount timer is basically just for going through the explosion animation and doesn't otherwise affect the game logic.  The only thing that I can figure extending the framecount would mess with is, it looks like the game does wait until the framecount is done before ending the level (so that you can watch the nuke animation finish, or watch the explosion from your final Lemming end) and this would delay the level end by one frame.

Still...  I will investigate for a fix that doesn't involve changing the framecount.

[namida]

At any rate, I'm going to move this topic out of the NeoLemmix bugs / suggestions board, as this doesn't relate to NeoLemmix.

[ccexplore]

I thought about this.  It looks like the Lemming is removed immediately, right when the particle framecount begins counting, and the framecount timer is basically just for going through the explosion animation and doesn't otherwise affect the game logic.

Hmm, unfortunately this would mean Lemmix is not currently emulating the described scenario 100% accurately based on my understanding.  I'd try to find a way to test and confirm on DOS Lemmings to prove this.  This should be fixed assuming I'm right.  The lemming can be hidden graphically but needs to continue to be counted as being in the level until it finishes all the frames of exploding particles, otherwise it will affect at least the nuking scenario I described.

[Aaron44126]

Hmm, unfortunately this would mean Lemmix is not currently emulating the described scenario 100% accurately based on my understanding.  I'd try to find a way to test and confirm on DOS Lemmings to prove this.  This should be fixed assuming I'm right.  The lemming can be hidden graphically but needs to continue to be counted as being in the level until it finishes all the frames of exploding particles, otherwise it will affect at least the nuking scenario I described.

Yes, I did notice that there is a behavior difference here.  In "proper Lemmings" (DOS, or Lemmings for Windows 95), the lemming does continue to exist after it blows up until the animation ends, which I can observe by looking at when the "Out" counter decrements or looking at the minimap which still shows a "dot" for the lemming.  In the Lemmix player, the lemming is removed immediately (the "out" counter decrements immediately and the dot on the minimap vanishes when the animation starts).  I figured that this was an intentional / cosmetic change.

There's this bit of code in HandleExploding which removes the lemming at the same time the animation frame counter starts.

Code: [Select]

      RemoveLemming(L);
      LemExploded := True;
      LemParticleTimer := PARTICLE_FRAMECOUNT;
      if (moShowParticles in fGameParams.MiscOptions) then
        fParticleFinishTimer := PARTICLE_FINISH_FRAMECOUNT;
It seems like any adjustments to correct this to accurately reproduce the DOS version nuking behavior would definitely impact compatibility of past replays (that involved nuking), am I wrong?

Anyway, turns out that I don't need to increment PARTICLE_FRAMECOUNT with this fix.  I flipped it back to 52 (along with PARTICLE_FINISH_FRAMECOUNT) and it still works.  The original explosion animation is 51 frames.  I just added a 52nd (empty) frame and there is still room to show it with the original cap.

So the list of changes is shorter:
https://github.com/AaronKelley/LemmixPlayer/compare/4e59cec..ef66c45

[ccexplore]

Here's a custom level that's perfect for testing the nuke scenario.  It's not a solvable level, but do the following:

1) Assign bomber to the lemming at the top.
2) After the bomber explodes (so you no longer see the lemming, you only see its particles), nuke.

The bottom two lemmings are arranged so that they are maintained at the exact same elevation as they both walk up their slopes.  So when they both eventually explode from nuking, the exact elevation of their respective bomb craters on their slopes will reflect how many frames occurred after the left lemming started its countdown before the right lemming started his.

I believe LemmixPlayer will currently show the right to explode 1 pixel higher than the left.  But the correct behavior as observed in DOS Lemmings I believe will have the right explode 2 pixels higher than the left--the same thing you'd observe if you started nuking earlier, anytime before the bomber has exploded.

I'll test on DOS Lemmings later today.  A screenshot and some quick checking in MS Paint will determine whether the correct difference in DOS Lemmings is 2 pixels vs Lemmix's 1.

[ccexplore]

It seems like any adjustments to correct this to accurately reproduce the DOS version nuking behavior would definitely impact compatibility of past replays (that involved nuking), am I wrong?

That can indeed happen.  However Lemmix has been taken as the gold standard for emulation accuracy of DOS Lemming's game logic, to the point that all replays from Lemmix for DOS Lemmings challenges are assumed to play out exactly the same when the same moves are carried out exactly on DOS Lemmings.  As such, this accuracy goal trumps the possibility of breaking past replays.

In practice, I expect very few replays to be materially affected:

1) The scenario I described require first having a lemming explode from bomber assignment (assigned before nuking started), and then start nuking during the explosion particles.  Even for the few solutions reported here that involve nuking, such a particular sequence of moves is rare if not yet ever used.

2) In some replays the scenario may perhaps happen incidentally, with the nuking only being initiated by the player for purpose of ending the level, rather than actually exploiting the explosive effects of nuking to pave a way to the exit.  And thus the nuking is basically pretty much always done well after other lemmings have exited, so that there's no chance it could affect a solution in terms of number of lemmings saved.  So even if there is an observable difference for the replay, at least it won't cause the replay to end up saving different number of lemmings.

[Aaron44126]

Ok, apologies for being new...  I'm not sure how to get the Lemmix player to open the LVL file that you posted.  Hints?  :-P

I see that there is a configuration option "LookForLVLFiles" and it looks like it will then try to load level files from the disk rather than from a level pack, in a format like "101.lvl" = "Fun difficulty, level 1".  I tried it renaming your TestNuke.lvl accordingly but it is still loading levels from the level pack instead.

Anyway, this is scope creeping a bit from my original goal which was just to fix the explosion animation for an unmaintained port of the game...

[ccexplore]

I don't remember, I think either you need to name file as 0101.lvl, or you need to also enable cheat mode before the option would take effect.  To enable cheat mode you go to the password screen (F2), type CHEATCODES and press ENTER.

Anyway, I don't expect you to try to fix this yourself, though you're welcome to try.  Otherwise at some later time I'll try to do the fix myself (along with including your fix for the stray particles) and rebuild the affected EXEs and have namida replace the ones currently downloadable.