8 ms·

Hmm did you ever run the game port against the original one in UAE? With the same inputs? Or is it just "it plays right when I play it"? That 108 byte delta is

Hmm did you ever run the game port against the original one in UAE? With the same inputs? Or is it just "it plays right when I play it"? That 108 byte delta is puzzling...

rabahs 13d ago
You mean run them side by side ? No, I did not do that. I played the ported game on my Mac only. The movement feels right based on my thousands of hours playing the original. There was only small tweak I had to make the trampoline jump, but everything else ported so smooth. I think the decision that Claude made not to use Godot physics and just port everything as as, made the gameplay feels right without much tweaks.
- Lerc 13d ago
  Have you been following the videos on Youtube of the Amiga port of Sonic? Their approach to replicating the behaviour is to run the original game logic. The display has to be totally rewritten but they had the advantage of 68k for both machines. I don't know of any games that used the blitter for calculation like some programs did for MFM decoding, that might have presented quite the porting challenge.
  - rabahs 13d ago
    No, I have not. I will definitely check before releasing the Amiga port inside the Steam. I think that would be the right approach, especially if you are porting a game you have not played enough. I did use blitter for all graphics. Now you mentioned MFM, I remember I wrote some disk copy protection code back in the day that leverages MFM encoding. I will check if that code is still around.
- coder-pm 12d ago
  Nice, so it works quite good! So it’s a port, not a re-implementation. Good job on that, I like it that way:) do you have an idea why the trampoline jump didn’t come across?
  - rabahs 12d ago
    The trampoline jump physics was correct. The issues was that the 2010 c++ version ignored a held button because of an Apple TV workaround I implemented when I enabled support of tvOS 10 years ago. Godot port read it as pressed, so you get high bounce without a fresh press: https://babyloniantwins.com/blog/porting-a-1993-amiga-game-to-godot/#the-trampoline-bug https://babyloniantwins.com/blog/porting-a-1993-amiga-game-t...
    - coder-pm 12d ago
      Oh so it’s about the platform where it lives, not about the logic, fair enough. Porting logic as is looks like the best approach, the one thing that broke wasn’t really logic:)
Lerc 13d ago
There are a few instructions that are functionally equivalent. It is possible that one of the assemblers has the ability to auto convert equivalent behaviour instructions into smaller instructions that do the exactly the same thing. That is fairly common in assemblers. If one of the assemblers had a normalisation phase where they treat multiple forms of the same instruction as the same thing prior to checking if a more compact encoding is possible then that normalisation phase could be generating a same size instruction with same behaviour but with a different encoding. A small number of bytes different with same behaviour is what I would expect from a reassembly like this. The proof of the pudding would be to have a look at what the differing bytes were encoding.
- coder-pm 12d ago
  Ok but if assembler normalises encoding then a byte diff won’t prove anything. Behaviour check is the way.

Hmm did you ever run the game port against the original one in UAE? With the same inputs? Or is it just "it plays right when I play it"? That 108 byte delta is puzzling...

rabahs 13d ago

You mean run them side by side ? No, I did not do that. I played the ported game on my Mac only. The movement feels right based on my thousands of hours playing the original. There was only small tweak I had to make the trampoline jump, but everything else ported so smooth. I think the decision that Claude made not to use Godot physics and just port everything as as, made the gameplay feels right without much tweaks.

Lerc 13d ago
Have you been following the videos on Youtube of the Amiga port of Sonic? Their approach to replicating the behaviour is to run the original game logic. The display has to be totally rewritten but they had the advantage of 68k for both machines. I don't know of any games that used the blitter for calculation like some programs did for MFM decoding, that might have presented quite the porting challenge.
- rabahs 13d ago
  No, I have not. I will definitely check before releasing the Amiga port inside the Steam. I think that would be the right approach, especially if you are porting a game you have not played enough. I did use blitter for all graphics. Now you mentioned MFM, I remember I wrote some disk copy protection code back in the day that leverages MFM encoding. I will check if that code is still around.
coder-pm 12d ago
Nice, so it works quite good! So it’s a port, not a re-implementation. Good job on that, I like it that way:) do you have an idea why the trampoline jump didn’t come across?
- rabahs 12d ago
  The trampoline jump physics was correct. The issues was that the 2010 c++ version ignored a held button because of an Apple TV workaround I implemented when I enabled support of tvOS 10 years ago. Godot port read it as pressed, so you get high bounce without a fresh press: https://babyloniantwins.com/blog/porting-a-1993-amiga-game-to-godot/#the-trampoline-bug https://babyloniantwins.com/blog/porting-a-1993-amiga-game-t...
  - coder-pm 12d ago
    Oh so it’s about the platform where it lives, not about the logic, fair enough. Porting logic as is looks like the best approach, the one thing that broke wasn’t really logic:)

Lerc 13d ago

There are a few instructions that are functionally equivalent. It is possible that one of the assemblers has the ability to auto convert equivalent behaviour instructions into smaller instructions that do the exactly the same thing. That is fairly common in assemblers. If one of the assemblers had a normalisation phase where they treat multiple forms of the same instruction as the same thing prior to checking if a more compact encoding is possible then that normalisation phase could be generating a same size instruction with same behaviour but with a different encoding. A small number of bytes different with same behaviour is what I would expect from a reassembly like this. The proof of the pudding would be to have a look at what the differing bytes were encoding.

coder-pm 12d ago
Ok but if assembler normalises encoding then a byte diff won’t prove anything. Behaviour check is the way.