MAMEWorld Forums - HBMAME / ARCADE64 / MESSUI - Patched Frogger

link to patched frogger set: https://file.io/LVYgJ7EZaMjm

philmurr from KLOV made a Frogger multi-kit and in the process disassembled the frogger code. After gathering a list of bugs he has corrected them all. Below is a link to the full patched frogger romset, but the only two files that were patched from the standard set are:

frogger.27
frsm3.7

More info here: https://forums.arcade-museum.com/threads/frogger-bugs-descriptions-and-fixes.482765/

Known (and repaired) bugs are:

1 – collision detection. It’s just about acceptable when on the road so I haven’t done anything to try to improve that. It’s not pixel-perfect, but as you can be jumping in the x-axis whilst vehicles are moving in the y-axis, it does an ok job of it. But on the river you can make perfectly good jumps to the end of the turtles or logs and still die.

The game sets up a table for each row of moving objects (logs, turtles), and stores the x-position of the right-hand edge of the object. The actual position stored is 2 pixels right of the edge of the turtles and 4 pixels right of the edge of the logs. It then tries to work out if you are on any of the objects by using the width of each object and seeing if your frog is in that right-to-left window. If it is then all is good, if not you’re in the water and you die. So it gets the far right location slightly wrong, the width of the object is too small, and it bases the compare point for your frog at the right-hand edge of it which causes all sorts of errors.

Rather than rewrite the collision-detection routines completely, I extended the width of the objects so they are correct and changed the frog compare point to its centre point which makes it much more accurate, fair and playable.

2 – Dying for no reason on valid jumps. It’s been suggested there are “invisible snakes” or other enemies on the logs that kill you. I don’t believe that’s true. There are 2 almost identical collision-detection routines that run dependent on which stage you are at in a vertical jump. It sometimes gets the calculation wrong as to which row of objects it should be checking against, so if for example you’re on the very right hand edge of the top turtle row then jump up onto the log above, it calculates you’re still on the turtle row, the turtle has gone from beneath you and assumes you’re in the water and you die. To get around this, for the water stage you don’t really need both collision-detection routines so I’ve bypassed the one that causes the issues (but still run it if you’re on the road stage).

3 – taking control of the frog in attract mode. When you’re on the top row of logs, the game is always checking to see if you’re jumping into one of the homes. Unfortunately the programmers didn’t first check to see if a game was in play and just check the player inputs anyway. Oddly there is some code immediately before where it jumps to that does this check, so a quick code diversion and I get it to check first if a game is in play, if not then it doesn’t test for player inputs and you can no longer control the frog in attract mode.

4 - If you’re on the bank (centre row) and jump up onto a turtle then back down, you can jump off the right edge of the screen (and can’t go the full distance on the left edge). The x-position of your frog is $10 ($=hex) when on the left hand edge of the screen and $E0 when on the right hand edge. When you jump, you move in multiples of $10 pixels so your position will always be $n0. But when you’re jumping around in the water and land on a turtle or log, you move by 2 pixels at a time. So your x position may not be $n0, but instead $n2, $n4, etc. The game only checks to see if you are greater than $20 if jumping left and less than $E0 if jumping right, so e.g. if your x position is $DE you can now jump right to $EE which is off the right of the screen. Likewise left, if your x position is $1E you’re not at the far left of the screen but it doesn’t allow you to jump any further left. To get round this, I did some code that checks how many pixels you can still jump (in multiples of 2, not $10) to get to the left ($10) or right ($E0) and allow you to jump that far, so you now stay on the screen.

5 - Jumping on the top row of logs sometimes goes very slowly. It has nothing to do with previously eating a fly. The game reads the player inputs, then directly afterwards is the routine to perform the frog movement. The bug where you move slowly happens if you try to jump when you are below one of the homes and it has already been filled. The game checks to see if the home is already filled and prevents you from jumping into that home again, but it brute forces it by simply not checking the player inputs (so also stops the movement from progressing). So trying to jump left or right just before when you’re directly below an occupied home will start the movement, then it will stop it whilst you are below the home, then start again when you are clear of it causing the odd stuttered movement. This was a bit trickier to fix, so I went for the solution of only preventing the up player input from being processed (if you allow it, then it lets you fill the home multiple times...). So allowing left, right and down to still be processed continued with the normal movement of the frog.

6 - the lady frog can sometimes be invisible, then appear out of nothing but a strange colour. It has something to do with the lady frog x & y coordinates being populated by the player coordinates when the player lands on where it should be, and the sprite being set to colour 0 (which gives the odd red colour).

Edited by McHale (06/19/23 07:47 AM)