Of course. It's your preference. But a quick question. Do you have now an AI assisted toolbox that helps you to put out this "recompilation" so fast after Ruff'n Tumble. We were all a bit surprised. Or was is a parallel developement over the years?
I will write a devblog post about the process one day for sure. What I can tell now is that it is an arithmetically exact C++ reimplementation from disassembled 68k machine code so it is basically fully precise, pixel perfect to a single tick. That's why these game play exactly like old ones, including all the quirks as well. There is no emulation of any kind. Assets are decoded and rebulit on the fly from original (or not really, I can't encourage people to use cracked ADFs on my game page so blatantly) disk images to a modern forms so png textures for atlasses and tiles etc. All copper tricks, blitter tricks, sprite tricks, palette tricks are gone, it is all replaced with proper moder rendering techniques . That means I can render what i want at any resolution and zoom level, while game in a runtime is so light it could run on a potato (if it had a screen). That's basically the gist of it. And while there is no magic AI toolbox that does things on a single click, with each new game there is less and less that is really custom and patterns start to emerge so I can offload more and more to automated processes and agents, There are finite ways to do a game on Amiga and there are finite ways to store assets. After some time it's all same old, same old
this is a great process (for a great result). How much time does it take to port a game like this? How are you handling the custom chip read/writes? And how can you do widescreen when the scrolling of those games is super-optimized not to have a lot of data on screen? I suppose you have to throw all the code away except for the high-level logic, which takes a lot of RE time.
Custom chip operations are rewritten by purpose. Copper lists, hardware sprites and colour-register writes are SDL texture draws and GPU effects so old calls are basically triggers of intent like „fade this screen to black in 50 ticks”. Paula channel writes become mixer commands (like music fade). CIA/beam-position reads used for timing become a fixed 50 Hz game tick to maintain correct game speed, joystick reads become normal input etc.
For widescreen, Original Superfrog maintains a small scrolling buffer and draws only newly exposed rows or columns. This version keeps the whole decoded level map available in memory, so a wider viewport can simply look up and draw every tile it covers. Coordinates, collision and integer movement remain unchanged. Objects also remain active in the wider view but behaviours based on the original screen distance still use an invisible rectangle that has size of original playfield and act as a proximity trigger. Like in Ruff n Tumble where enemies don’t chase me from across the super ultra wide screen.
I won't tell how long it took to ship Frog as it would raise many eyebrows (and probably make some people upset)