whoopdedo 3 hours ago

Look at the subroutine `EnemyMoveGetMaxRowBot` starting at line #9353. On #9414 the data row pointer is set to the enemy's current row. On #9441 it checks if the column to the left is a pole. On #9516 it checks if the column to the right is a pole. Now notice that on #9461 the row pointer is moved to the row below so it can check for a walkable tile (brick or ladder). When the right-side check is done after a left-side check the row pointer will be on the wrong row.

Here it is in C (from my own notes)

    SetCurrentRow1(y);
    if (CURROW1[x] != 0) {
        if (x != 0) {
            if (CURROW1[x-1] == 4) {
                TargetY = y;
                if (y >= PlayerY)
                    return y;
            } else {
                SetCurrentRow1(y+1);
                if (CURROW1[x-1] == 1 || CURROW1[x-1] == 2 || CURROW1[x-1] == 3) {
                    TargetY = y;
                    if (y >= PlayerY)
                        return y;
                }
            }
        }
        if (x < 27) {
            if (CURROW1[x+1] == 4) {
                TargetY = y;
                if (y >= PlayerY)
                    return y;
            } else {
                SetCurrentRow1(y+1);
                if (CURROW1[x+1] == 1 || CURROW1[x+1] == 2 || CURROW1[x+1] == 3) {
                    TargetY = y;
                    if (y >= PlayerY)
                        return y;
                }
            }
        }
    }
The bug can be seen on level 29 if you stand on the left set of blocks that has a single gold in it. The enemies will get stuck on the second ladder which has a pole on the right side.

The Apple II, Atari 8-bit, Commodore 64, and naturally the VIC-20 versions of the game have this bug since they were all made by Broderbund. But interestingly so does the Hudson Soft NES port. The later Macintosh version, which is otherwise a direct port of the Apple II code, fixed it. The IBM-PC version didn't have this bug because it was rewritten with the memory layout column-ordered instead of row-ordered. But then introduced a similar bug by subtracting when it should be adding.

(edit: I hadn't checked until just now but I'm amused to find that Lode Runner Legacy from 2017 preserved this bug in the classic game mode.)

  • BolexNOLA 2 hours ago

    You just dredged up a deep memory. Is this the thing where the enemies would keep going up and down a ladder just generally speaking? I don’t know if I ever made it to level 29, my memory is not that good lol, but I do have memories of enemies just constantly going up and down ladders occasionally.

krajzeg 5 hours ago

Just wanted to note: this is in no way the original source code for the game. It's disassembled and commented source code.

Here is the repository owner explaining the process himself: https://github.com/Piddewitt/C64-Game-Source-Code

Nice work and interesting still, but maybe we can correct the title?

  • indigodaddy 2 hours ago

    Ah didn't realize this, I just copied the title used in the GH repo. Too late for me to change the title, but maybe an admin will.

  • cogman10 4 hours ago

    ehh, for these old games that's pretty close to the same thing.

    A lot of old games were written in assembly. The difference between the disassembled and assembled code is/was pretty minimal.

    What you ultimately lose out on is the comments and perhaps jump location names depending on the assembler.

Luc 5 hours ago

This can't be the original source code.

https://github.com/Piddewitt/Loderunner/blob/main/Lode%20Run...

Original source, I imagine, would be very tersely commented, if only to fit in memory / floppy, and would have very short variable and subroutine names, and lots of mess and commented-out lines from experiments.

This looks like a very lovingly done disassembly.

  • taink 3 hours ago

    From the repository's README:

      Commented source code of the C64 Lode Runner Game - Including the copy protection
evereverever 4 hours ago

I just went to a talk at Portland Retro Game Festival by the dutch guy that made an official Atari Lode Runner port. He said he found a japanese book that had the C source in it and got the enemy AI from that.

This is pretty cool.

rileytg 5 hours ago

this is a great remake of the Load Runner follow up, Mad Monks Revenge. it works amazing on a modern macOS!

https://mmr.quarkrobot.com/

  • emmelaich 4 hours ago

    I'd love to play a LodeRunner with the same feel as the original. No version I've tried has the right feel. It's subtle.

    Is this good? I downloaded but Virustotal said 1/66 vendors gave > "MaxSecure Trojan.Malware.300983.susgen Acronis (Static ML) Undetected"

    Probably a false positive but enough for me not to try it.

  • eek2121 3 hours ago

    WOW thank you for this!

bluedino 4 hours ago

I don't think I ever played an actual 'Lode Runner', just Steve Moraff's version (DOS shareware?)

Whatever happened to that guy?

kenjackson 5 hours ago

I love how well structured these old 8bit asm games always seem to be.

rhyperior 5 hours ago

oh my, they used my favorite solution for the how to draw a circle interview question

phendrenad2 6 hours ago

Aaaaah it's one 21k assembly file (including data in hex format). Step #1 for anyone trying to port this to another platform will be to split it up into smaller files, no doubt.

  • snvzz 5 hours ago

    A license is not present, as to enable derivatives.

    It will still be a while until copyright expires, unfortunately.

    • Pannoniae 4 hours ago

      fortunately, you don't have to care about those details, just go and do it ;) I don't think the original person who decompiled someone else's intellectual property has too much ground to stand on here lol