Month: June 2009

I cleaned up the code and a few bugs and I`m satisfied with the current state, so I`m releasing the binaries today.

Some common terms for all versions:
The binaries posted are only intended for the Amiga-Versions of “Monkey Island”, use the regular ScummVM for everything else.
To report bugs, first make sure they are bugs – means check if the Amiga Version behaves differently by running it on an emulator or on the real hardware. Differences to MSDOS or other versions dont count.
A special note to music-quality: The Amiga had a lowpassfilter which is emulated by UAE/WinUAE (you can disable it in the options), but not within ScummVM. Also those Emulators have several expensive interpolation-methods which again ScummVM is lacking. Especially the missing lowpass filter is noticeable, but apart from that the output should be very close.

So, without further delays, here are executeables for Win32/Linux32/Linux64:

Nothing stops you to compile it yourself of course, look at the previous Blog-Post for the Link

Update: While playing a bit further in MI, I found out that the effects in the mansion where a mess. I fixed them and compiled a new set of binaries (I really hope these will last longer): (Editor’s notice: This file was hosted on the now defunct hosting provider hotfile[.]com. It is not available anymore.)

Update2: Please report any bugs in the ScummVM-Forum

Support for soundeffects dint take much of my time, but I`m in the middle of exams and tests right now so work on ScummVM slowed down alot. Im still improving the code and will put out some new binaries to test soon.
Since I seen requests regarding the code in the comments, I`m working on a branch of ScummVM, so you can use this to look at the source or compile it yourself. By default it will compile ScummVM with working TFMX Support, defining TFMX_CMDLINE_TOOL will result in a spartan commandlinetool to playback TFMX Modules (aslong they are called “mdat.monkey” and “smpl.monkey”).

As said I will post some binaries soon, and since “Monkey Island” is working with sound and effect, this will conclude my initial work on TFMX and next up is Maxtrax/Kyrandia. I would ask you to use this time to thoroughly test “Monkey Island” and report any weird behaviour or inaccuracies regarding sound/effects. I`ll probably make a thread on the forums for this, seems more suited for this than commenting on a blog.

I dint so much coding work, but I researched a bit on the inner workings of ScummVM and Monkey Island.

A TFMX-Song doesnt need to have an end, it can loop a section indefinitly or even just repeat the same sample all over. Yet Monkey Island has a coulple of scenes like the intro where the game waits a preset time to show up the MI-Logo and then waits for the song to stop before loading the next scene.
Yet the corresponding TFMX-Song (#4) has no ending, the only reason it does end is because I added some additional checks that did work nicely in the case of the intro. The same checks fail on another Song (#3) which runs endlessly. So its time to explore how this kind of timing works in the original Amiga-Version and how ScummVM expects it to work.

Timing on the Intro is twofold, I could not find any reference in the TFMX-Player that would signal the time the song “really starts” (after just some ambient sound, sorry cant express this better 😉 ), even if that would be easy to archive it hasnt be done. Instead the original executable must have a own counter which runs independent of the music-playback, but Im not going to reverse the whole executeable to find out how this is done exactly.
ScummVM does poll regulary for a “musictimer” and counting 1/25 seconds since songstart seems to just about work (guess the timer is a multiple of the 50 VBlank interrupts per second). Still would be good to hear from some ScummVM Devs if there are some custom hacks for MI Amiga already in place.

Ending of songs however is something thats controlled indirectly by the TFMX-Player. A TFMX-Song has special commands to talk back to the application – writing values to a shared block of Memory, perfect to notify if a specific pattern has be reached. And the songs in question (#3 and #4) both use them to signal the end of the Song. They do so by writing a 1 to a shared Memory Block at start and writing a 0 to the same position at the end. (and song #3 just loops and overrides the value with 1 again!?).
Since ScummVM aint providing a function which directly correspond to that I will have to figure out a way to make this work seemlessly, it already polls if a song is still running so I will try putting a check for this flag. Still that might not be enough as not all Songs set this flag to 1.

Alot happened since my last post, this probably means I should update more often. Unfortunatly Im rather the type that adds just-another-thing(tm) before bragging about it.

When I did the last post I was very motivated to improve the quality of the playback, which proved to get more and more difficult. The quality of the music posted on the 6th June was already good and what was left was implementing a few more effects Monkey Island is using and finding bugs which affected playback. Implementing new effects is rather straightforward, but some new effects suddenly caused heavy regressions aswell. I was already past the point beeing able to rely on the available opensource TFMX-Players (tfmxplay) so this meant timeconsuming reversing of the “Monkey Island” executeable. In the end the most trivial bug kept me occupied a whole day. Around the 10th June I had a Player which supports all effects Monkey Island is using.

Today I managed to enable sound support for Monkey Island, looking at the scumm-engine I initially felt totally lost. But with the help of one of the ScummVM devs (_sev) I found the hooks already waiting for my code. Its still hackish and maybe even causes problems sometimes during the game, but you can try it out for yourself: (Editor’s notice: This file was hosted on the now defunct hosting provider hotfile[.]com. It is not available anymore.)

Now what up next?

I found out a couple of  things while adding MI-support, for one than not only the music but also the sfx are done with TFMX. Its not documented anywhere how these are invoked and I got to reverse and add this to the player aswell. And of course improve the integration into ScummVM.

While cleaning up and verifying my code I was able to fix a couple (stupid late-night) mistakes and this caused an immense improvement. Before You needed much imagination to hear out correct melodies, but now everythings sounding mighty fine. Ironically this kept me up late night once more for potentially making more stupid bugs.

I shouldve kept some before/after recording, I just have some recordings of the current state: (Editor’s notice: There was a link to the now defunct hosting provider hotfile[.]com. Unfortunately, the file is not available anymore.)

I cant believe its almost 2 weeks since I started working on this, the long weekend sure helped with that.

My project went well so far, no big issues yet except beeing behind my own schedule. But luckily theres enough time to compensate for that and I worked a bit “sideways” by running a bit through the disassembled MI Executeable which will surely be handy.

I succeded in creating a simple replayer, it steps through the TFMX-Modules and even outputs … noise, its not anything close to what it should sound like yet. I spent the last day (rather night) trying to fix playback but no joy so far. I modify the player to just run a single channel on a part of a module so I can locate the problem easier.

I chosen to implement the bigger part first by beeing able to run through whole Modules, in retrospect I could`ve focused on playing back simple segments of it first and then improve upon that – might have been faster alltogether. I`m always smarter afterwards and sometime it might require running my head against a wall first.

On the other hand, now that I have the routines ready, the player should gradually get into shape as I fix the parts, which is very motivating to see. =)

I expect to be able to play back parts of modules the next few days, then clean up everything to have a solid base for further improvements.

So far I more or less have a simple player which steps through patterns and tracks. Still not much of a joy since I cant really verify everything is working as intended, the reason for this is for one the complexity of the format. Unlike eg. Protracker, there are 8 independend channels for patterns(which can loop, jump or have subroutines each), so there is no easy way to visualise whats going on the whole player.

For another reason, the player (both the OS tfmxplay and the disassembled MI-Executeable) dont give much hints or have many sane restrictions and checks about parameters. It would be quite easy to craft TFMX-Modules that result in both these players ending up in an infinite loop (in more possible ways than you could count). Probably it is even hard not to do so when you just naively try to create a module.

Im now trying to produce some sound, which means I have to implement enough of the macros and effects together with tracking their state so I can atleast playback some samples. I hope I will be there in ~2 days, I gone from re-coding everything myself to copying stuff from tfmxplay and adopting it to my needs. This should speed up my short-time progress at the cost of having to cleaning it up or reimplementing later. I really want to literally hear a lifesign of my work.