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)
I don't see why it would make people upset. Personally I re-made a few titles on SDL or Java like Supercars 2, Gods, Bagman, and attempted Magic Pockets but stopped as it was too much work without using the original source. If you publish a PC version of Magic Pockets in 1 week I'd be very happy (I even have designed extra levels). It wouldn't shock me the least. (as maybe you know) I do amiga ports of arcade games, and without A.I. (only with scripting) sometimes I can convert a game in 1 week (using more or less the same method as you but more low-level, with transcoding and MAME-like appoach for graphics), and people are also surprised by the speed. But why spending 3 years re-doing/porting something that already exists? Keep it coming. What I'd love to see is the Bitmap Bros games done. Not sure Mike Montgommery would like it though, as Gods & Chaos Engine ports exist and sell on steam (it's a scam: no extra levels, same exact graphics, except for Gods where you can choose shitty unity crap graphics instead of original). Also Cadaver, but with A.I. enhanced graphics (more colors).
About the shitty graphics, the best part is that with how I handle data means all assets can be replaced with nicer ones. Basically adfs are all read at once and all assets are decoded and "cooked" to SDL digestible forms like in memory file store, so all tiles, sprites are at game init built to modern textures, all quirks like sprites originally made from few separate parts are on the fly cooked to full modern, assembled sprite atlas etc. And there is pak file that is layout wise like a pre-cooked version of adf-based in memory storefile where all decoding happened offline, currently i cook this pak file with no original assets because of copyright reasons but if I put all assets there, game would work with no ADF bacause it seeks assets in pak and if missing, fallback to adf so if i created like remastered hero.png file with all the frog anim frames and put it in pak file, game would use it and just ignore ADF. Basically game seeks all assets from pak and reads from adf only when pak doesnt have equivalent. The same with music where game can use original player or play OGG files with metadata for where to loop.