"Mario & Luigi" (1994-2001, DOS) - building and porting

[Nimbus]

It gets compiled to executable, but hangs in a loop without printing anything and throws INT 6h all over the place.

So I wonder if there are actually bugs in the code. Of course there might be, sure, but hadn't thought about bugs in the compiler itself!

What I noticed when I tried to build a simplest i8086 program using the trunk FPC recently, the only way I could get a runnable EXE is with the Huge model. Any other model (of course I built the RTL for every model I tried), resulted in corrupted stack during the startup, and glitches like that. I didn't go too deep and I know this doesn't help much, just sharing what I saw.

[_skrzyp_]

A quick report for everyone.

Today I made the game working on FPC 3.3.1-trunk, at least in 85%.
Thanks to few people which I had close contact with for last couple of days, they'll be credited in final release. Sadly, it's not about anyone from this thread... yet.

Anyways, these are current changes:

• To fix the famous IOMAR & GILUI as well as tileset offset in title screen:
  
  I just swapped {$S+} to {$S-} to disable stack checking in MARIO.PAS. I am not really sure if that's a bug or does it actually work as intended and there's some padding in these data-as-code procedure added. But it works fine without them.
  
• To fix the garbled keyboard inputs:
  
  I've swapped all the arrays from 1-indexed to 0-indexed in KEYBOARD.PAS so the GetKey asm procedure would work properly. Also moved for-loop indexes from 1 to 0, decreased MaxKeys accordingly by 1 and decreased all keyTTTTT... constants by 1. It might be simpler to fix the GetKey procedure instead, but it worked fine with TP7 somehow. Actually, the whole keyboard logic could be probably simplified a lot more, but this is a job for later stage refactoring.
  
• To prevent sound from causing Runtime 200 error on eating the mushroom:
  
  I've modified the Beep function so it won't call Crt.Sound anything below Freq = 19, everything above that works properly. Sadly, this makes that famous sound of mushroom not playing properly at all, but I think it could be fixed properly in the future.
  
• You might need to still comment out ReadConfig and WriteConfig calls in MARIO.PAS but it's not always required, more on this below.

Issues still remaining:

• The DOS calls in ReadConfig / WriteConfig are not working properly and game is crashing with INT 6h. These are used to store "save data" and sound/statusline on/off. Also joystick calibration, but who the hell would play this game with analog joystick.
  
  But, the DOSBox sets the DOS version to 5.00 by default. If I change it manually to 6.22, these calls seem to... at least not crash the game. However, the MARIO.CFG is not created when leaving the game, and the settings are not read properly. I sense a bug in FPC RTL, the original still works properly even with DOS ver = 5.00.
• The Mario sprite gets garbled after reaching Level 3. It's back to normal when you jump off from cliff and lose a life. Screenshot attached.
• Some sounds are not playing correctly, see above.
• Not directly related to any of these current issues, but there seems to be a nasty bug on FPC trunk which actually prevents you from build "Hello World" on any memory model except Huge. I've just opened an issue on FPC bugtracker and waiting for any remediation to come.

Things to do:

• I've intentionally didn't push any of these changes to GitHub repo and I'm not uploading them verbatim, asking you to change the code on your own. That's mostly because I need to reach out to Mike Wiering and ask him about providing the exact license to his code. I know the aspect of free software licensing is an alien concept for most Pascal users, but I'd like to process forward without waking up some day with takedown notice. So even just admitting that code is Public Domain should be okay, but ideally I'd plan to relicense it on MIT license and I need to research how to do that properly first.
• If granted, clean out the initial patch and push it to GitHub repo
• Also start providing CI/CD builds for testing
• Check the DOS filesystem API bugs in RTL using minimal examples and report to FPC bugtracker if confirmed
• Examine DEMOKEYS.OBJ and provide correct code instead as this was the only unit without a source. You can link with it or without, it won't change how the program works as long as you comment out Macro and references.
• Provide some way of testing the game, maybe seek out for DOSBox build with TAS support.

[TBMan]

I've found DOSBOX to be a little wonky. I've used it to run Borland Pascal 7.0 and it was ok, but like I said, wonky.

With today's computers being so fast, you don't need to do direct memory writes for graphics. I did a game or two using them and ported them over to using Lazarus and PTCGraph, PTCMouse and PTCcrt. PTCGraph supports page flipping which I have used in almost all of my arcade-like games (see my signature for the videos).  The only thing I haven't tried is a joystick, but I bet there is code out there somewhere for that. Good luck in your project though, it looks like fun.

[paule32]

If you need a Game / Graphics Framework then take a Look to ALEGRO.
It is for DOS with Page Flipping, Flood Fill, and some Graphic Effects like a Hotspot Lamp that you can move/display with the Mouse ...