[WIP] Frogger conversion

[JoeJoe]

After a visit to the computer games museum in Berlin, I decided to convert an arcade game as well. I chose the game "KONAMI 1981 Frogger".
My wife had played this game very intensively. At that time, she had also played the whole thing on the PC.


This is also a 1:1 arcade port using of course the original Z80 code that I reverse-engineered & transcoded to 68000.

My thanks go to jotd for the very nice and helpful conversation. Even without his z80268k tools you would work on the implementation for a very long time.


What is currently missing is the complete sound. The animation and the additional enemies are also missing.

Personally, I learned a lot from this work. First of all, assembler for Z80. Then how the hardware of the machine works. Also interesting is how the code from 1981 works. I also found a few bugs.

[ Show youtube player ]

[acidbottle]

This is amazing, great work and look forward to it's eventual release

[TCD]

Looks good Seems like eventually we'll have all the Z80 based arcade machines 1:1 on the Amiga

[nikosidis]

Looking great! Nice classic.

[jotd]

this is great!

[malko]

Well done
Waiting the version with snd & sfx

[amiman99]

I can't wait to try it!

[JoeJoe]

Thank you all. Here is a small update:

- Points calculation now works
- Turtles are now swimming around happily

In one or the other place we would like to optimise the original code. But I will try to leave it as untouched as possible.

[jotd]

in my experience optimizing the code should be done in the amiga specific section (blitting, display). A lot of "tst" instructions can be removed after a move to D0 instruction, but that's not that will make the game fly!

[JoeJoe]

I agree with you completely. Wordwise reading and writing on odd memory areas is also impossible for the 68000. But who am I telling? You are the master of conversion.

[Girolamo85]

So cool, very nice work!

[JoeJoe]

I wanted to give you a short update on the current project. The conversion has been completed so far. For the time being, the game works as a whole. The following points are still to be done
- SFX
- Music
- Adjust game speed (damn 60Hz vs 50Hz)

Also the colouring of the sprites gives me a headache. There are 7 sprites and each one can have a different set of colours. Horizontal or vertical multipliers are not possible because the sprites overlap.
Displaying some sprites as background objects is also not possible due to the many different scroll levels.
hmmmm....The only thing that still has room would be in dual playflield.

Maybe one of you has an idea, every word is welcome.
Cheers

[jotd]

To adjust game speed Don Adan provided a good trick: every 5 vblank, update twice (draw only once!)

It's really invisible but catches up with the speed.

There are 7 sprites and each one can have a different set of colours. Horizontal or vertical multipliers are not possible because the sprites overlap.

now you hate Amiga designers with their 8 sprites & color coupling.

You can go AGA each sprite has its own palette. But it's pretty overkill for such a game.
Or decide that some sprites will be bobs instead (and have to refresh the background).

Each game I did used a different approach:

- Pacman: used sprites for 4 ghosts with each own color palette, so back to bobs (1 bitplane, no cookie cut at all) for Pacman, bob for bonus
- MsPacman: same for ghosts, cookie cut blits for MsPacman & bonus
- Amidar: same as MsPacman, with some more logic because there are up to 6 enemies and sprites may change colors depending if they're killed or not. Some sprite sorting => worked.
- Scramble: no sprites, only blits because I thought it would conflict with background stars.
- Xevious: mix between BOBs & AGA sprites (to get more colors) with dual playfield 16/16. Shoehorned
- Galaxian: same configuration as yours: 7 sprites. But I knew right from the start that it wouldn't be possible, so I used sprites only for player shot, flagship score & explosions, using an allocation engine to group same color sprites together (sometimes failed.)
- Pengo: pretty proud of my sprite allocation engine, coupled with copper color change & a bit of luck because color hacks are only needed in demo/intro screens and there are no color collisions (or barely noticeable)

In your case, I would use a sprite for Frogger & often displayed enemies, or alternately for objects that need a different palette, and use Bobs for the rest...

[JoeJoe]

First of all thank you jotd for your answers. You are quite helpful.

To adjust game speed Don Adan provided a good trick: every 5 vblank, update twice (draw only once!)

That's a pretty neat trick. With a little adjustment it runs almost perfectly.

  ...
  ; adjust NTSC speed ;)
  lea       AdjustFrameCount(pc),a6
  sub.b     #$01,(a6)
  bne.s     .notagain
  sub.b     #$01,(1,a6)
  bne.s     .normalcount
  move.b    #$03,(1,a6)
  move.b    #-1,(a6)
.normalcount:   
  add.b     #$06,(a6)
  bra.w     .runagain

.notagain:
  ...

I will then represent the otter via bob. The rest of the enemies are Sprits.
The goal is for the game to run on a basic A500 with only 512MB of ram.

Latest Version (with Speed Fix):
[ Show youtube player ]

EDIT: Inline Youtube not work :/

Beta is comming sooon

[saimon69]

Not a coder but you could treat the layers of traffic and logs like a rolling strip and modify the tiles at need (unless you are doing this already)

[jotd]

Yes, I reckon from our private conversations that JoeJoe already does that using partial scrolls (and that's pretty neat). That's how the original hardware operates (same hardware as Galaxian).

Given the number of lines I think that the blitter could possibly not cope! On Galaxian I could use that trick (because copperlist was busy with stars scrolling) and used blitting, but there were only a few rows to update so it was OK.

Every problem a different solution.

Excellent job JoeJoe!

[str0m]

This looks great. I play the original cabinet at my local retro arcade, damm the collision detection can be annoying/rubbish at time but sounds like yours will be identical which is the best way to go to give the proper experience

[JoeJoe]

Thank you for your feedback and congratulations.

Then I'll blunder out of my bag of tricks.
For the representation of the tree trunks, turtles and vehicles, I use a total of 10 strips that are rotated horizontally. One revolution is exactly 256 pixels wide. As a result, if the graphics don't change, I don't need to "blit" a single time. (Hmmm the A500 can only do 15 pixels^^) The hardware of the machine can do the same.
Blitting a bob across the different stripes is possible, but time-consuming. To do this, you have to split the bob at the transitions and "blit" twice.

Let's continue: Currently I only use 2 bitplanes. So strictly speaking only 4 colors. However, the machine can assign a different color set of four questions to each line.

the collision detection can be annoying/rubbish at time

The collision calculation is the same as in the arcade. Unfortunately sometimes a bit spongy. There are fixes for the version but I want to keep the original state.
A revised version might be possible. But where does this end? You could then beautify the graphics and so on...

The high score is also not saved. But you I do this with just a few lines. But that would no longer be original.
A arcade machine only keeps the points in memory until it is disconnected from the power supply. Unfortunately, I don't know if there was a "memory module" back then that saves the high score in the event of a power failure.

cheers

[kamelito]

How many colors is there in Frogger doesn’t look much, isn’t dual playfield an option with Copper colors change if needed so no need to save and redraw the BG?

[JoeJoe]

The background is not a problem here. Because I'm already showing it correctly. It's more about the sprites. These have 3 colors + 1 transparent and of course not the same. So if 7 sprites are displayed at the same time, I only have the problem with two competing sprints. But I'll solve that by blitting the otter.