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.)
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.
An enemy will try to reach the same floor height as the player, and if it can't it will prefer climbing up over climbing down. It also looks left then right for another ladder or free-fall that might bring it closer to the player's height.
In the case of level 29[1], the best position on the second ladder is to move to the top then use the horizontal pole to move left. That's what it will do when below the right-side pole. But when it gets above that it switches to thinking it should move down. Because the goal changes it gets stuck in the loop of moving up then moving down.
What you may be thinking of is when the "best" position is at the top of a ladder but no clear path left or right. It will climb to the top so the only way to go next is down. But after moving down immediately wants to go up again.
I'd say no. We would have had the Itanium drama 10 years earlier. The i860 had some flashy features in it (integrated graphics, SIMD) but also the same Achilles' heel as Itanium of compiler-directed pipeline ordering. That made it much slower than other processors and any analyst of the time would have recommended staying on x86 for the performance and not having to change all your software. So AMD and Cyrix sell more chips and Intel has to backpedal to avoid completely losing the PC market.
In case this thread gets picked up by a search engine and some future person is wondering the same thing, there is a port of winevdm[1] to 64-bit Windows that will let you run 16-bit programs.
I expect there's some selection bias at play. If you're taking a philosophy major in college it's likely you already feel confident in your post-graduation career, so can study things that you like. Whereas if you're in a CS track it's because whether you get a job depends on getting a degree. The student studying philosophy is in school as an alternative to work. The STEM major is in school as a prerequisite to work.
Or Philosophy is usually a path to Law School on the professional path or a PhD on the research/academia path. In both cases, many/most of those 22-27 year olds are still in school and thus not counted as unemployed.
I don't know how true it still is with law being, to a fair degree, perhaps primarily a good career path for those who can land at white-shoe firms and federal court clerkships. But I've known a lot of people who drifted into law school from liberal arts and related because they just didn't have great job prospects. And quite a few didn't even end up practicing law.
IBM marketed "OS/2 for Windows" which made it sound like a compatibility layer to make Windows behave like OS/2. In truth it was the OS/2 operating system with drivers and conversion tools that made it easier for people who were used to Windows.
Untrue. OS/2 for windows leveraged the user’s existing copy of windows for os/2’s compatibility function instead of relying on a bundled copy of windows, like the “full”
Os/2 version.
Os/2 basically ran a copy of windows (either the existing one or bundled one) to then execute windows programs side by side with os/2 (and DOS) software.
If you ever sent money to or from a wallet you control, I'd think a reliable recovery factor would be to use that key to sign a message that Coinbase can verify with the address in their records. Cryptocurrency after all is just another PKI.
And dumb-dumb me just realized how trivial that would be to break. Social engineer someone into sending/receiving money to/from your wallet then pretend to be them requesting an account recovery.
Coinbase would have to make you sign a challenge ahead of time that would mark the wallet as the authorized public key for your account.
Here it is in C (from my own notes)
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.)