Mike! I want to ask you...

Started by DragonsLover, January 16, 2005, 05:14:19 AM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Proxima

Quote from: guest  link=1105852459/75#87 date=1119435483Unless you're mixing the bomb explosion mask of Cheapo with the screenshot from "The Lemmings Solution" site or something.  :???:
Of course; how else do you expect me to do it? The Mac takes ages to start up, so I'm not going to do that just to test how many pixels deep a bomb hole is.

However, I should have been more explicit, because I was trying a couple more of the "Challenges" I did take the opportunity to experiment on the Mac, and that's what my last post refers to.

Mike

lol.... What are you lot like.... They should be 60 pixels, or its been hacked.

Heres the actual Amiga code, and the PC code will be the same (I can probably find it somewhere...)

Each time a lemming drops 1 pixel, it checks to see if its hit ground, if it has, it jumps to this.




StopAndCheck      cmp.b      #60,LemmingFallCount(a0)      the fall counter
      bls.s      FellOK
      tst.b      LemmingFloater(a0)
      bne      FellOK
      
      clr.w      LemmingAnim(a0)
      bset      #LemmingSplatting,d6
      bclr      #LemmingExploding,d6
      clr.b      LemmingCountdown(a0)
      move.l      #LemmingSplatBase,LemmingAddress(a0)
      clr.w      XDirection(a0)

      move.w      #$13<<8!FXSplat,FXNumber(a5)
      move.w      LemmingX(a0),FXPosition(a5)
      bsr      PlayFX

      bra      NextLemming

FellOK      bclr      #lemmingFalling,d6
      MakeWalker
      bra      NextLemming

Mike

PC Version.....  So there you go   B)


MaxFallCount            equ      60


StopAndCheck:      mov      [si.Lemming.yc],bp
            cmp      [si.Lemming.FallCount],MaxFallCount
            jbe      FellOK

            MakeSplatter
            jmp      NextLemming

FellOK:            MakeWalker
            jmp      NextLemming
ProcessFall      ENDP

DragonsLover

So, the answer is: [size=8]60[/size]

Nothing else!
I like dragons! They're the center of my life! I'll never forget them...

guest

Hmm...well, anyone has a copy of PC Lemmings in its original disks to test it out?

It's hard to argue with Mike's source code, but......

(Of course, to be completely unambiguous we'll really need to see more source code, in particular to check whether it is really the case that each increment of fallcount corresponds visually to falling down by 1-pixel.  We also need to make sure fallcount is correctly initialized before a fall to 0 and not, say, -1.)

guest

Quote from: DragonsLover  link=1105852459/90#93 date=1119478234So, the answer is: 60
Nothing else!
As much as I trust Mike, as I pointed out in the previous post, there are ways for which what that snippet of source code seems to say differ from what actually happens in the game.  I still think it'd be good to do a test with a copy of Lemmings from the original disk.

Mike

:)

okay.... for the curious....

A lemming "pixel" is the one right under his feet. This is the one that he walks on. When thats not there, and the one below that is, then he has fallen 1 pixel.  so...


***********
******************


This is a 1 pixel fall - except he'll walk this. A Lemming will "walk" down up to 3 pixels. 4 and over he turns into a faller. (he'll "jump" up 6 pixels BTW). So a drop of 60, should visually BE 60. This is EASY to test if your determined. Using Windows lemmings, you can easilly edit a level (by hand if you need to) to place blocks 60 pixels appart. You could then do one 61 pixels appart.

Timballisto

If you ask me, I'm happy to just go with sixty- I mean, what does it affect if it isn't?  If you need to know for level editing purposes then just adjust the cliff until it's good.  If it's for solving a level, then just test the cliff during play.  If the lemming dies it's too high.  If not then (state the obvious here).

guest

Well, since LemEdit displays the coordinates of your pieces, having a precise number means you may be able to avoid having to guess-and-check your way to the height you want.

Other than that, just a matter of curiosity...well actually, no.  For the various Lemming challenges, sometimes it might be critical to know whether the falling distances certain parts of a solution rely on is universal or not.

Since Mike mentioned how the game treats a 3-pixel drop as a "walk" rather than a fall, my gut feeling is that, the fall count probably only starts counting when you go past the 3 pixel "walk", which would very nicely explain a cliff of 63 pixels that my numbers are indicating (60+3=63).  But then again my 63 pixels might be just for my copy of the game.

Hence the need for someone with an original-disk-condition copy of the game to test and settle......

guest

Quote from: Mike  link=1105852459/90#96 date=1119479124:)This is a 1 pixel fall - except he'll walk this. A Lemming will "walk" down up to 3 pixels. 4 and over he turns into a faller.
I'm starting to think it is very likely that my 63 and your 60 are the same.  Since the source code you produce seems to specifically process fallers, if lemmings aren't turned from walkers into fallers until after heading down 3 pixels (which sounds like what you're talking about), then this would account for the cliff height of 63 I was getting, as 3 + 60 = 63.

Feel free to produce additional source code to support or refute.  ;)

Mindless

Sorry to break the "fall height" discussion, but...
@Mike: Would you happen to know where the PC version of Lemmings stores the level order data?

Mike

The 3 pixels that a lemming "walks" down, are included in the 60 pixel drop. so it's 60, not 63.

-----------

There is an indirection table for levels. So when on level (say 4), it might tell you to load level 15 instead.

Below is the table I have. The numbers have to be divided by 2. If the bottom bit is set, then its a duplicate, and it gets the new skills from an "odd table", which is loaded in from "ODDTABLE.DAT".

These are levels that have new skills to make them easier. So if the indirection table has the bottom bit set, its a duplicate level, with overidden skills. The PD version, doesnt use an indrection table, and while the data disk does(Oh NO!), it doesnt use the odd table.


; Fun Levels
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;147,155,157,149,151,153,159,14,22,54 &#A0; &#A0; &#A0;
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;70,16,29,32,38,42,48,72,84,104
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;138,23,68,96,98,116,78,100,108,134

; Tricky Levels
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;1,30,36,50,52,56,58,80,102,120
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;128,130,136,5,148,152,154,156,160,7
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;11,13,15,17,19,21,25,27,33,31

; Taxing Levels
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;37,39,41,43,45,47,49,51,53,55
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;57,59,61,63,3,65,67,69,71,73
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;75,77,79,81,83,85,87,89,35,111

; Mayhem Levels
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;91,93,95,97,99,101,103,105,107,109
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;112,113,115,117,119,121,123,125,127,150
 &#A0; &#A0; &#A0;db &#A0; &#A0; &#A0;129,9,131,133,135,137,139,141,143,145

guest

Quote from: Mike  link=1105852459/90#92 date=1119477399PC Version.....  So there you go   B)


MaxFallCount            equ      60


StopAndCheck:      mov      [si.Lemming.yc],bp
           cmp      [si.Lemming.FallCount],MaxFallCount
           jbe      FellOK
Ok, I searched the disassembly of my copy of Lemmings.  To my relieve, I was able to locate the "cmp [si.Lemming.FallCount],MaxFallCount" line and MaxFallCount on my copy is indeed 60.

So I can now be fairly confident that my copy is not hacked with regards to MaxFallCount.  The discrepencies between my observations and Mike's assertions must then have to do with other parts of the code.

I try locating nearby lines of code that references [si.Lemmings.FallCount].  I found three more that come before the MaxFallCount compare line, but it's hard to unambiguously make out their significance without first understand all the surrounding code in between.

There is one line that compares [si.Lemmings.FallCount] to the value 16.  I'd guess this probably has something to do with when a floater starts floating.

There is one line that adds 3 to si.Lemming.FallCount.  This really doesn't say much though without seeing how the Lemming's y-position changes.  However, notice that even right off the bat, this means a fall of, say, 62 pixels, may still be survivable, depending on when exactly the "add 3" occurs.  Namely, if "add 3" doesn't occur until you've truly fallen 3 pixels beyond where you were after the previous "add 3", then if the fall is 62, you would still survive since the next "add 3" only comes on 63.

And the earliest line I found assigns the value 3 to si.Lemming.FallCount.  Again, doesn't say much without knowing how the Lemming's y-position changes.

---------------------

Intriguingly, whatever the resolution with regards to the falling distance, we now have the information necessary to hack (or in my opinion, fix) CustLemm so it obeys the correct falling distance.  We just find the cmp [si.Lemming.FallCount],MaxFallCount line and change the value of MaxFallCount there (back) to 60 and that should do it.

Of course, I doubt anyone would want this, since there are probably quite a number of CustLemm levels out there that depends on CustLemm's higher fall distance, but the possibility is still there.

guest

Quote from: Mike  link=1105852459/90#101 date=1119534386If the bottom bit is set, then its a duplicate, and it gets the new skills from an "odd table", which is loaded in from "ODDTABLE.DAT".
Oh, so that's why it's called "oddtable" -- the number would be odd (as in, not even) when the bottom bit is set.

Proxima

Unfortunately, it's the other way round! Levels with odd numbers are originals; levels with even numbers are duplicates. (Look at Mike's list of numbers. Fun 3, for example, has no duplicate, and is odd.)

On the Mac, if you open the levels with ResEdit, the even ones correspond to resources with no level data, just skills and level statistics -- these are obviously the duplicates, since they don't need level data of their own. However, the resource type for these is called an ODDL (as opposed to LEVL) so it still contains the word "odd".......

Another interesting fact is that, in most pairs, the harder level is the original and the easier level is the duplicate -- as expected, since the harder ones were made first. However, this isn't true for Fun 1-7 (the training levels). Were these made before the harder versions? (That would make sense, both because it's easier to imagine someone thinking "Let's start with training levels for the different skills" than "Let's make easier versions of these as training levels" -- and because, with the one exception of Fun 4, the harder versions slot neatly into place before the harder versions of the later levels.)