Working on my TAS I've decently reverse-engineered how the data of a lemming is stored, and what data is stored about it. Since the MD/genesis port is very similar to other ports, this may also be true for systems like Amiga and DOS. However there are still some MYSTERIES (fun!), what are byte 10, 13 and 14, and what is skill 19.
Each lemming has 16 bytes stored about it. These chunks of 16 bytes are stored in an array, starting with the data about the first lemming to enter, then the second, and so on. In the version I have, this array starts at address E6B4 in the RAM.
Things found by geoo are in blue text, more details in 3rd replyNow for a byte-by-byte breakdown of what exactly is stored about each lemming.
BYTE 1: The "half" of the level it is in, if it's in the left half the value is 0, if it's in the right half the value is 1. Basically it's just an extra bit for the X-position of the lemming. Hacking this value to be >1 doesn't seem to result in the lemming being erased, instead it gets "stuck in a wall" rapidly alternating left and right, but not visible in the level.
BYTE 2: The standard X-position of the lemming, all values are used
BYTE 3: The Y-position of the lemming. 0 is the top of the level and 174 is the bottom. There is a "ceiling" at value 8 though and it is impossible to go any higher with current knowledge. The actual bottom of the visible level is 160, but the lemming dies at Y-value 174. Hacking any higher values causes the lemming to instantly die, though hacking it to be it's maximum value causes the lemming to wrap around to the top of the screen, and fall all the way down again with no collision, before dying as usual.
BYTE 4: This one seems to control the X-offset of the sprite used by the lemming, with different skills requiring different offsets to render in the correct position. I have found a single non-hacking glitch where this seems to go wrong, using a climber glitch in terrain, and going through a blocker field may make the sprite render a bit further to the right than it's actual position would suggest for a few frames.
BYTE 5: Same as above, but for the Y-offset.
BYTE 6:
Each bit in this byte is a different propertybit 0: direction
bit 1: climber flag
bit 2: floater flag
bit 3: removed from level
bit 4: player
bit 5: blocker related
bit 6: blocker related
BYTE 7: This cycles through the frames of the lemming's sprite animation.
BYTE 8: The skill of the lemming!
0 Walker
1 Oh-noer
2 Drowner
3 Instant Explosion
4 Faller
5 Jumper (used when going up steps greater than 2 pixels)
6 Exiter
7 Climber
8 Hoister (when finished climbing)
9 Shrugger (when finished building)
10 Floater Start
11 Floater
12 Splatter
13 Digger
14 Blocker
15 Miner
16 Die in fire trap
17 Builder
18 Basher
19 Occurs when a floater is assigned as a lemming is falling
above that causes game to crash
BYTE 9: Bomber countdown. Is set to 79 when a bomber is applied and decreases by 1 every physics update cycle. Turns into an oh-noer when this reaches 0.
BYTE 10:
Counts up by two every physics update cycle when a lemming is floating down, seems linked to the floater sprite animation. BYTE 11: Combined fall distance and builder countdown. It counts up when a lemming is falling to keep track of fall distance, to check if it should splat. When a builder is assigned it counts down from 12, reducing by one each time it lays a step (every 15 physics update cycles). This counter is only reset when the lemming becomes a builder or a faller
or a blocker.
BYTE 12: This changes based on what sort of object trigger area or terrain it is in. For example it is 0 when in air, 1 in an exit trigger area, 8 when in a steel area. Haven't really looked into what each number means. This does not seem to actually affect the lemming's actions though, hacking it to be 1 does not cause the lemming to exit for example, and it is reset back to a normal value the next physics update cycle.
BYTE 13 and BYTE 14:
UNKNOWN never seen these change,
however is referenced in blocker-related codeBYTE 15 and BYTE 16:
Work together to give address in memory where to find the sprite's animation: "if you look in the ROM, the value of these bytes plus 0x40644 give you the address where to find the sprites for the state (BYTE 8) this lemming is in. The exact offset also depends on the animation frame of the lemming (BYTE 7), and is computed in the skill-specific rendering code from off_9156 and off_9FC4. For example, for the walker or jumper, you'd find the ROM address of the current sprite of the lemming by taking 0x40664 + 0x168 (the value of BYTE 15-16 for walkers) + 0x28 * (BYTE 7). The sprites are encoded with 4 bits per pixel, and I believe for the walker the dimensions are 8x10 (not sure where the game gets the width and height of each frame from)"
Show Posts
