ScummVM for Atari... Its woes and future (hopefully)

The woes with ScummVM....

ScummVM is an amazing piece of software, and also is extremely complicated. That fact that it currently runs on high end Atari machines is amazing. I believe, currently the Atari/FreeMiNT platform is the lowest end platform supported. There use to be an AmigaOS port for 68k, but I believe that is no longer the case.

Anyway, the port is still without it's numerous problems. I guess I am here to try to list those. Can they be fixed? Hopefully, the problem is getting the amount of dedicated time to do this work.

One of the biggest problems has been sound. Adlib emulation takes a huge hit on the CPU, and that is using the older included emulation code. The newer code is even harder on the CPU cycles. Now, between SDL 1.2.9 and 1.2.11, there was a great increase in the speed of the sound handling, so Patrice made some extremely useful optimizations. But, I seem to hit up with sound race conditions (or maybe not) in some games, so, unfortunately, all officially released versions of ScummVM are using the older SDL.

Now, for instance, I can run Monkey Island 2 - LeChucks Revenge (DOS) with almost no issue using newer revisions of SDL. The game plays close to original speed if not at 100%. The 1.2.9 revision of SDL has some lags but is pretty good. Now, Indiana Jones and the Fate of Atlantis (DOS CD Talkie) runs just about full speed with new SDL, but will randomly crash anywhere from 5 to 30 minutes, while with SDL 1.2.9, stable, but some lag. I think a sound race condition is introduced because of the efficiency of the newer SDL in these talkie games, since ScummVM is producing both an Adlib music stream and a digital speech stream. This is one problem I have not been able to figure out at all, but I could be wrong in this thought. While GDB has been wonderful in some other troubleshooting, with this crash it is of little use because there is no code to look at to see where the crash occurred. But then, this theory could be wrong from another issue and approach I was taking to fix it....

ScummVM really wants threads to be able to use timers. As far as I know, timers are used in quite a few engines such as Sierra's AGI engine, the SKY engine and some of the more modem Scumm games, as well using any midi music driver. I have never been able to get threads to work with ScummVM (pth), and ScummVM does not like the included vbl timer Patrice did in SDL, and I believe Patrice thought that possibly the code segment was too large. Now, I was able to hack ScummVM, and this patch has never gone into the official source, but was given the OK with additional work, to fire the timers through screen updates. This works well and allows ST Midi music to work (out to an MT32 on my Falcon), along with AGI games (I completed Space Quest I) and some other titles. Although, I still get the wierd crash with Talkie games like Fate of Atlantis, even though one stream of sound is taken out of the picture. This sort of makes me question the whole idea of a possible race condition. GDB is still of no help here. Also, the timer hack works great with the newer revisions of SDL, but causes crashing with 1.2.9, the version I use for releases.

Another problem is memory usage. Memory usage is not a problem at all when used in MiNT, but seems to be a huge problem in TOS and MagiC. I have never been able to run a game in ScummVM in TOS, and do not have MagiC, while others have been able to do this. But they can only run smaller games, and not larger ones. While I have not spent too much time on this issue, I'm guessing there is a problem with how memory is used between ST Ram, and FastRAM. It seems MiNT does not care, while maybe TOS is dumping ScummVM into ST Ram. It has been a while since I messed with this, since I hate having to constantly reboot to test, but it is a problem that I need to get figured out. Besides flags, I tried messing around with redefining how the mallocs worked, which did not get me anywhere.......

Another current problem I have is that binaries compiled with -m68020-60 do not work. So, I have been back to building 68000 versions for a while.

Well, that lists the main deficiencies I know of. Improvements? Well, there is already a midi driver I added into the ScummVM tree that works on my Falcon with hacked timers. I have been toying around with trying to add a midi -> ym driver, although that still needs a lot of thought to figure out if this is really worthwhile. This is more of a way to reduce the load on the CPU. Also, as previously mentioned, trying to make use of the DSP is on my radar as well. I want to see if I can offload some Adlib functionality to it, and possibly MP3 decoding since using compressed sounds files currently is just too heavy of a CPU load.

Anyway, there you have it. The status of ScummVM. Even with the problems, it is still incredible it works on the platform, and I think the majority of the thanks go to Patrice Mandin for his SDL work. Maybe some of this long winded post should be added to the next readme. :)