Planet SoC -

Summer’s end

Buddha — Tue, 19 Aug 2008 01:21:28 +0200

Hi! Google Summer of Code 2008 just ended and I thought that it’d be good to make a new blog entry about where I got during the last days of GSoC and talk a bit about the overall experience.
Status update
The problem I was having with player movement last time really was just that, the player movement routine (executePlayerInput) was incomplete. Once I reverse engineered Operation Stealth’s version of it and modified ScummVM’s current implementation (r33872) of that function a bit I got the swimming working and I could get to the girl and free her:
Freeing the girl in ScummVM
I might as well tell a bit about what happens in the game after that:
The player character and the girl swim to the surface and are rescued by a boat:
Being rescued by boat
The story goes on and they meet The Movement for The Liberation of Santa Paragua for the first time:
Meeting the movement
Then they leave to infiltrate a palace:
Leaving for the palace
And enroute to the palace some masking bugs
Masking bugging while enroute to the palace
And then after a cutscene at the palace there’s another arcade sequence: A labyrinth.
The labyrinth
Okay, so far I’ve gotten to the second arcade sequence which is a labyrinth:
First labyrinth
But there are some showstopping problems here. The player can be controlled but the doors that should revolve when walked against don’t revolve and so the arcade sequence is not yet completable.
I played Operation Stealth using DOSBox to the labyrinth and used DOSBox’s debugger to look for the collision data page (And I found it! Yay!) and dumped it to a binary file. What I wanted to do was to compare the original’s collision data page to the ScummVM’s version in the labyrinth to see if there were any differences that could be breaking the gameplay. And voila, there were! Here are some pictures:
First labyrinth's collision data from DOSBox
First labyrinth's collision data from ScummVM
By the way the collision data page can currently be viewed in the Cine engine by pressing F11 (I added that in r33877).
I tried loading the collision data I dumped from DOSBox to Cine’s collision data page and yes, I got the doors to revolve! But alas, they didn’t yet work totally correctly, sometimes you could just simply walk through a door like it was thin air and sometimes a door would shake between two frames of animation a bit weirdly.
So it’s looking like at least there’s something wrong with how Cine currently manages the collision data or how it’s loaded. I checked the collision data loading routine loadCtOS and the data conversion routine gfxConvertSpriteToRaw that it uses. It looks like the gfxConvertSpriteToRaw is indeed correct, I reverse engineered a version of it myself from Operation Stealth’s disassembly, tried using my own version of it but it didn’t seem to make a difference at all. So that particular routine doesn’t look to be the culprit here.
Release testing related bugfixes
With the next stable version of ScummVM being prepared and release testing in progress I got some Future Wars related bug reports and did some bugfixing:

Adlib sound related bugfix to fix a crash when teleporting to the swamp (r33935 trunk, r33937 0.12.0)
Fix for overparanoid monks beating player unconscious (r33950 trunk, r33951 0.12.0)
Fix for crashing when examing rubble above a manhole (r33967 trunk, r33966 0.12.0)

And with those fixes in place Future Wars’s English DOS floppy version should now be completable using the 0.12.0 branch.
Reported Future Wars bugs still unfixed
There are some regressions and bugs still left in the Cine engine though:

Bug #2057656: FW: Assert during demo (regression)
Bug #2057637: FW: Spaceship glitches in demo (regression)
Bug #2057619: FW: Glitches in title display of demo (regression)
Bug #2055912: FW: incrustSprite fails on savegame loading
Bug #2055836: FW: Music is not restarted when loading a saved game
Bug #2019344: FW: crash with Amiga Italian version (photocopy room)

What I learned during this summer
Ok, enough about the status update, here are some points I’d like to make about what I learned during this summer of code:

A lot about reverse engineering - I feel a lot more competent in it now than I did before this summer - and in particular that IDA’s graph view is simply essential, I wouldn’t dream about going back to not using it when reverse engineering something. It’s just absolutely essential, no doubt about that.
Tried Valgrind for the first time and it looks like a good tool to have around when fixing memory corruption problems. I recommend giving it a go if you have memory corruption problems in a software you’re developing!
Tried DOSBox’s debugger for the first time and it looks also to be a useful piece of software, although I probably don’t know half of what can be done with it yet.
That I’m not always as productive as I might like to, my effort changes with the tasks I’m doing. So knowing how to focus and get things done even though the task might not be to my current liking is something I haven’t yet truly mastered. I’ve heard that if you are completely present in a situation and totally focused on something then that something *becomes* interesting, whatever it may be. Now that’d be a lifesaving thing to know how to do - maybe some meditation (e.g. Zazen) would be in order?
That I probably take my work too seriously at times: Getting something working felt great at times and not getting something working felt awful at other times. Or maybe it’s simply human nature to feel like that? Dunno. Anyway, I should probably know when to relax and let go, simply do and not measure my worth by what I get done but by the effort I put in regardless of the outcome (Yeah, quite the Gandhi talking :-)).

What’s so good about this reverse engineering thing anyway?
All in all this summer was a learning experience for me. What I found particularly interesting was the reverse engineering bit, taking a function in disassembly, looking at how big and intractable it looks and then starting on it, bit by bit, part by part making it more and more understandable until what you have in front of you is something you actually are able to understand. An example:
This is the graph of executePlayerInput function without any work done on it yet.
Here's how the function looks after quite a bit of abstracting done on it.
And here's the highest abstraction level graph that I made of the function.
It’s quite a bit of work, I tell you, but it’s quite riveting (There’s that focus thing again. I mean, just take a look at what Merriam-Webster says about the word riveting: “having the power to fix the attention”). Yeah!
What about the future?
I’m still committed to making Operation Stealth completable although it’ll be outside this GSoC. I’ll be fixing some of the Cine engine related bugs for the upcoming 0.12.0 release of ScummVM too.
Closing words
I’d like to congratulate everyone who made it to the end of Google Summer of Code 2008! It was an interesting ride, glad so many people with such diverse projects could get along for it. Thanks Google!
And last but not least thanks to my mentor Eugene for guiding me to a more productive direction in my work at times during this summer. His sane voice was the voice of practicality and, I imagine, experience.

PICTARZ!1

Tanoku — Tue, 19 Aug 2008 00:09:51 +0200

I’m throwing a pretty crazy end-of-GSoC party over here, so I thought I’d post some PICTARZ (TM) of the GUI as it’s on the branch right now, because I’ve been promising them for quite a while. That’s pretty much it folks.

Also, while I’m at it I might as well share a video which is a must watch in order to be considered a worthy human being:

UPDATE: Apparently, it looks like my artistic retardedness made me paint half of the GUI pink instead of yellow. The usual folks at IRC pointed that out - as always. ;D
I commited a fix… It was just a one-line change thanks to my awesome idea of using color palettes instead of repeating color values. </egotrip> It’s actually *yellow* now - I checked against the trunk version. Go me.

Official end of summer post (warning: wall of text)

Tanoku — Mon, 18 Aug 2008 21:26:46 +0200

That’s it, folks.
Google’s Summer of Code is officially over (it’s been over for about 20 minutes now). I thought I’d write the mandatory long post where I talk about my experiences during the summer and all that. So here it goes.
The ghost of The Old GUI
I obviously had lots of fun during the project, and I knew since the beginning I was going to enjoy the experience. I applied with 3 projects for GSoC and the three of them involved hefty amounts of graphics programming because basically that’s the only thing I can spend a whole summer working on.
On the other hand, I wasn’t really expecting the experience to be that harsh (enlightening, yes, but harsh). First off, when writing my application I went so overboard with features, plans and schedules that after a quick review I almost wanted to cry. I obviously didn’t, because I’m such a manly man. But still, you get the point… A vector renderer from scratch, a new format for theme description, a new parser for that format… the list goes on and on. After all, it hasn’t been a sweatshop-like task, that’s for sure, but let’s just say I would have liked to spend this summer a little more time closer to boobies and a little more more time away from GDB.
And then there’s also the issue with feedback. Massive, scary feedback. When you write that many lines of code, you always have lots of bugs. And the more code you write, the more bugs that pop out. And you fix them.
But the thing is that I’m not writing code here. I’m rewriting on top of a massive code base that has been written over the course of many months, and has been mature for many more months. And there’s always that ghost roaming your project: Your GUI not only has bugs… It has glitches. It doesn’t do this or that the old GUI did. It does that but it doesn’t do it in exactly the same way. THAT TEXT IS OFF PLACE!!
And it can be a tad nightmarish. Facing the ghost of the Old GUI can be a pain in the ass. But I’d say I’ve defeated him; with the help of many people, of course, and based of tons and tons of negative yet necessary feedback. That’s why I’d like to apologize (again) if I ever reacted in a moronic-witty manner towards the so required and welcome feedback I’ve received during the summer. Either way, I’d say that it turned out quite good.
Oh how I love thee, Mr. Schickel
I’ve just read this morning on LordHoto’s blog (yes, I know, I’m kind of late… I like that) that he feels he hasn’t been a good mentor at all. I guess that wasn’t really serious (maybe it was just a temporary dramamoment!), since it usually goes the other way around: Students think that they haven’t been up to the task. But whatever, the fact is that I think I have been a great student (HA), and I also think he has been a more-than-great mentor in many many ways — so I just wanted to point that fact out. And to thank him again for all the work he’s done during the summer.
And while I’m throwing props around, I’d like to send some to my favorite overlords from hell, Max and Eugene, just for being there, for all the work they do, for being supportive and for being downright cool.
Lastly, I’d like to bow down before DrMcCoy. He has really been the living incarnation of the Ghost of The Old GUI this summer. I actually had a couple dreams about him. BAD dreams. But I’d like to point out how much I appreciate all the time he has invested on me and my project when he obviously wasn’t required to do so. Really. Thanks tons. bows down
A status report
LordHoto asked me for a status report -and what a better place to do it than in this final blog post.
The new Graphical User Interface has traveled a long way this summer - from being a simple pixel-renderer to being a… huh… an actual Graphical User Interface. It still has bugs -all programs do- and it still doesn’t replicate the old GUI pixel-per-pixel (read the book I wrote on the ghost of the Old GUI). But it’s there, standing still after just 2 months of work. Ok, make that three months. But you get the point.
As I stated above, I went completely nuts with my goals. And I’ve ran out of time. Somehow, I did actually divide goals on my Application into “Main Goals” and “Optional Goals”, and that’s a good thing, because whilst I’ve managed to take on all the main goals -and accomplished them in a pretty good manner, I must add-, I haven’t really had time to even think about optional goals (those were TTF fonts and localization support, basically). I guess that kind of fits into the meaning of the word optional.
But anyways, enough talking about what hasn’t been done; let’s talk about what has been done.
I’m really happy about the outcome of the project. In fact, I’m actually hyped about the outcome - in the middle of the summer, I wasn’t really expecting it’d end up like it. I may probably be ego-tripping here, but I’m really proud of much of the code I’ve written this summer. The vector renderer design is smart, and it’s really extendable (although that was basically LordHoto’s idea, but whatever), and the new STX format is… Straight and simple. I think it’s a good idea. The way that drawsteps work, and specially, very very specially the way that Flowing Layouts work make me all tingly on the inside.
Either way, I do acknowledge that the GUI has its issues and its shortcomings - many of these because of the fact that I’ve run so out of time. Besides a few graphical glitches (i.e. when replicating the old GUI), there’s one big issue in the GUI in my opinion: the shadow renderer. It does not look good and I know it - the shadows aren’t even soft, although I must admit it is quite fast. That’s really calling for a rewrite, and I’m sure that there are lots of other places that could use some work (performance, anyone?), and lots of places that could use some testing; the kind of stuff that you do without pressure or schedules. But that’s gonna have to wait a while…
So what happens now?
Right now, and to celebrate that the GSoC is officially over, I’m going to fade out for two weeks to work on some personal stuff while LordHoto takes up the daunting task of evaluating my summer work.
I really need to forget -at least temporarily- about graphical user interfaces, XML, vectorial drawing and all the kind of stuff that has been haunting my mind during this summer.
After the evaluation period is over, I’ll be back (read that in a menacing voice), and I’ll resume my work on my project until it’s solid enough to be merged into the trunk. We’ll see how it goes - and after that no one knows what will happen. I’ll probably start contributing to Residual if next years university schedules allow me to do so. That project really needs some love!
So, this is it for this summer folks. Thanks for reading, I’ll see you in two weeks from my new blog (I kind of need a new one, I don’t think I can take this Scummer of Code pun any longer).
And no, this time there are no jokes regarding plane tickets to Germany and kicking some witty german ass. Why should I?
Out, -Tanoku.

What’s up, doc?

Tanoku — Fri, 15 Aug 2008 01:40:58 +0200

So… yes, right. Doc is up. And by doc I mean documentation. And by up I mean that a first draft of the Theme Format documentation has been uploaded and can be seen here. It even has PICTARZ, so feel free to take a peek and tell me what do you think I could improve (apart from the obvious missing sentences and the hundreds of typos). And don’t tell me I can improve PICTARZ because they are the most awesome shit you’ll ever see in a XML format documentation. EVAR.
Also, in case you don’t know, I have been working my ass off this last week. Yesterday I dropped all traces of the legacy GUI code from my SVN branch (if that’s not a project milestone, then I don’t know what is it).
This afternoon I’ve written a whole theme from scratch (a reproduction of the old “classic” theme) in less than 1h. I guess that proves that the new STX format is powerful or something.
…And that’s it. I’m basically done. There are just a few graphical glitches here and there (the new GUI doesn’t look exactly like the old one) which I’ll be fixing over the weekend.
I wanna be Jackie Onassis. I wanna wear a pair of dark sunglasses. I wanna be Jackie O, oh, oh, oh please don’t die.

What’s up, doc?

Tanoku — Fri, 15 Aug 2008 01:40:58 +0200

Memory corruption hunting

Buddha — Wed, 13 Aug 2008 18:57:56 +0200

Hi! I’ve been fixing lots of things in Operation Stealth. I started using Valgrind because the Cine engine corrupted memory and I didn’t know where to start fixing it. I’ve now got Valgrind running ScummVM under Ubuntu 8.04 which I’m running in VirtualBox. A virtual machine (VirtualBox) running a virtual machine (Valgrind), yay! One could think that it’d be dead slow, but actually it runs ok.
So I recommend trying out Valgrind if you’ve got memory corruption problems with a program you’re developing even if you don’t run Linux natively, it can be used through a virtual machine like VirtualBox, QEMU or VMWare. I already got some memory corruption problems fixed with Valgrind’s help.
Stuff done since last update:
Bugfixes:

Fixed popup boxes blocking animation (r33686)
Partially fixed Adlib volume setting (r33700 trunk, r33701 0.12.0)
Fixed ‘text hard to read’ problems (r33792)
Fixed inventory showing (r33795)
Fixed verb handling bug (r33805)

New functionality:

Implemented game speed changing by pressing - or + (r33689)
Added moving using keyboard (r33698 & r33710)
Basic support for CD Future Wars (r33703 trunk, r33705 0.12.0)
Added drawing of type 22 overlays as filled rectangles (r33713)
Preliminary drawing of type 21 overlays (r33721 & r33722). WIP!
Implemented transparent cutscene textboxes (r33790)

Cutscene textboxes working in ScummVM
Memory corruption and out of bounds access related changes:

Fixed rectangle drawing (r33687 & r 33811 trunk, r33814 0.12.0)
Added sanity tests to background scrolling (r33688)
Converted objectTable to Common::Array (r33725)
Converted animDataTable to Common::Array (r33726)
Converted zoneData & zoneQuery to Common::Array (r33727)
Converted partBuffer to Common::Array (r33783)
Converted palPtr to Common::Array (r33785)
Fixed fontParamTable freeing (r33786)
Converted commandBuffer to Common::String (r33793)
Fixed handling of incorrect input data in loadMsg (r33810)
Fixed initialization of instrument data (r33812 trunk, r33813 0.12.0)

Cleanup:

Removed unnecessary textDataPtr (r33784)

And as Valgrind noticed some memory problems in the AGI engine’s sound engine I committed some fixes related to them (r33816 & r33822 trunk, r33820 & r33823 0.12.0). I had previously noticed that the AGI engine’s sound engine sometimes crashed when starting the first sound in an AGI game, so hopefully that’s fixed now.
What next?
Well, I got to the part where the player character is dropped into the sea with a woman, but I’m currently stuck there. After sorting out the memory corruption problems and testing the original game’s behaviour in this particular part it seems the problem is somehow related to incorrect character moving. The character should first swim near the girl and then try “Operate Girl” to untie her ropes (It works that way in the original). Here’s a picture of the thing working in DOSBox:
Freeing the girl in DOSBox
But alas in ScummVM currently the player character can only be moved to the left and he automatically moves upwards almost all the time. So I can’t get to the girl to untie her and they both drown. With the memory corruption problems out of the way I’m looking into fixing this character moving problem next.

Saturated

Tanoku — Tue, 12 Aug 2008 01:00:39 +0200

I’m exhausted. Really burned out. I’ve had to take a day out from coding -and I spent it writing documentation, which is sad enough.
The theme format documentation is coming along nicely. After that, there’s this TODO list:
- Finish builtin theme.
- g1x dialog boxes/options
- Theme loading: Theme names, theme headers.
- Button corners too big, widgets gigantic
- No shadows on top of the widgets (rework shadows engine)
- Popup widgets could use 2 triangles
It’s a bit of work but I have the whole week. Unless I decide to throw my computer down the balcony. I promise there’ll be a proper update in the middle of the week, and a big “end of gsoc” post on the weekend.
I really have a hard time expressing myself in english; this documentation writing thing is giving me a serious headache.

Got through the first arcade sequence

Buddha — Thu, 07 Aug 2008 14:28:28 +0200

Hi! Got through the first arcade sequence in Operation Stealth and back onto dry land :-). But it wasn’t very easy, as there were problems to overcome:

First arcade sequence was practically impossible to complete (Oxygen forced to maximum by a hack in r33667 for now so it’s possible to complete it)
Player teleported to a wrong location when getting out of the water after the first arcade sequence (Fixed by fixing checkCollision function’s boundary checking in r33668)
Player got completely stuck after getting out of the water after the first arcade sequence (Introduced a hack in r33673 to nudge the player off his position by one pixel to get him free)

Here's where one could get stuck after the first arcade sequence
So now the first arcade sequence is completable (Although by a hack) and one can get out of the water after it and continue playing.
BTW while playing I’ve noticed that although savegames work good enough to allow continuing playing the graphics aren’t always correct, see for yourself:
Beach scene bugging after loading a savegame
What next?
Carrying onwards with the game! Let’s see how far I’ll get this time without encountering any showstopping bugs…

Got to the first arcade sequence

Buddha — Wed, 06 Aug 2008 15:04:19 +0200

Hi! Played the 256 color PC version of Operation Stealth under ScummVM to the first arcade sequence. Found lots of bugs but only one that was a showstopper (Crash when leaving the airport) and another one that may be a showstopper (Moving in the first arcade sequence is so hard that it may be practically impossible to complete it). Fixed the former bug already but not the latter one. Here’s a list of the bugs I found:
Bugs found on first completion run try so far
#1: Verb-handling bug:
If you open the briefcase with “Operate briefcase” the operate-verb will stay chosen and then you can choose “Operate calculator” again and again etc and it becomes “Operate calculator calculator calculator…” and finally crashes.
Verb handling bugs
#2: Background handling bug:
If you load a savegame that has the briefcase open the palette and the background will be wrong (If you opened the briefcase in the bathroom stall the background will be the bathroom stall but with wrong colors. Pen, passport and calculator in the briefcase are shown on top with correct colors though.
Briefcase's background bugs after loading
Briefcase's background works after not loading
#3: Airport bag conveyor belt masking bug:
If you go to the airport’s bag picking up scene where bags run in a circle on a conveyor belt then you’ll see that the scene looks pretty weird. Some masks are probably off… (Things go in front of stuff that they shouldn’t or something similar).
Conveyor belt masking bugs
Conveyor belt masking working in DOSBox
#4: Fading bug:
If for an example you go to the airport’s bathroom stall and open and close the briefcase you’ll get a double fading effect.
#5: Inventory showing doesn’t work unless using the USE verb:
If you right click to get the menu and choose INVENTORY nothing happens. It should show the inventory. If you choose the USE verb you’ll get to choose an item to use from the inventory though.
#6: Game crashes or player is invisible when exiting the airport:
First the game crashed when trying to leave the airport when it didn’t find some files JOHN01.ANI and JOHN02.ANI. Fixed the resource loading to handle missing files gracefully in r33643. After that the player character was completely invisible when walking behind the glass in the next scene. Looked into that and made a workaround by loading the corresponding SET files instead (It worked and looked fine) in r33644.
Player visible behind glass after workaround
#7: Music may hang on a note when scene changes:
If for an example you leave the airport by a taxi and go downtown the music playing outside the airport may hang on a note and continue playing that single sound. The sound is quite annoying.
#8: Text hard to read:
For an example in the Santa Paragua’s bank when examining the stained glass door on the back the background of the popup box is light yellow and the text is white so it’s very hard to read what it says.
Text hard to read
#9: Text box wraps around the screen:
A “WATCH OOOOOUT!!!” text box wraps around the screen from the right to the left side in the Las Mimosas park during the drive-by shooting.
Text box wraps around screen
#10: Masking bugs at the hotel’s beach stairs:
This might very well be just like the next bug but when walking to the stairs that go down to the hotel’s beach in Santa Paragua the masking bugs and the player character can seemingly walk through the railing.
Masking bugs at the hotel's beach stairs
#11: Masking bugs in the bank vault in Santa Paragua’s bank:
When going to open the safe case in the bank’s vault in Santa Paragua the player character is seen in front of the bars although he’s walking behind them. The masking works later though… weird.
Vault bar masking bugs
Vault bar masking works
#12: Popup box blocks animation when it shouldn’t:
After getting caught by the enemy agents in Santa Paragua’s bank there’s a scene where it reads “Later, after a hard trip…” and the enemy agents and the protagonist walk from left to right on-screen. They don’t walk at all if one doesn’t click with the mouse (They should be animated even though there’s a popup box on-screen). So you can only get through the scene by clicking with the mouse many, many times but still, it’s possible.
Popup box blocking animation
#13: Game jams after failing first arcade sequence:
If you die by being underwater for too long in the first arcade sequence the game jams. Nothing happens, music just keeps playing and the “It isn’t recommended to hang around underwater. This is the end of your exploits” box is shown and the loading menu can’t be accessed.
#14: Red bar that shows the oxygen left isn’t updated:
In the first arcade sequence the bar should show the amount of oxygen left but it doesn’t, it simply stays the same long red bar all the time (Still you can get killed by being underwater for too long).
First arcade sequence
#15: It’s very hard to move in the first arcade sequence:
The player character doesn’t move much if you just click once somewhere on-screen and keep the mouse button down. Neither does using the keyboard do any good (Movement using keyboard isn’t implemented yet, I think). So you just have to click furiously with the mouse to where you want to swim in order to get there. This may make the first arcade sequence practically impossible to complete.
What next?
Alright, I got to the first arcade sequence but it’s hard to play it. I’ll fix that so it can be played through and then carry on!

No Cigar

Marwan Hilmi — Wed, 06 Aug 2008 08:05:58 +0200

As time to the deadline winds down, the pressure is building up. Since my focus has been on programming and dealing with the outstanding issues, I have neglected updating this blog as frequently as I would like.
As it stands, with the latest update, I believe the issues with the update cycle and timing system should be resolved. The previous revision had several problems due to the patterns or macros terminating prematurely or not stepping properly. With the revised system, song playback is handled as follows:

The TFMX files are loaded with a separate functions to load the data and samples. Once loaded, you call playSong() to start playback of a particular track. This loads the track data, starts PAULA and the interrupt cycle.

On the first interrupt, the trackstep data is read. If the trackstep line specifies a command, it is processed and the trackstep proceeds to the next line on the next interrupt. If the trackstep specifies patterns in one of the eight tracks, a flag specifying that a pattern is on is set to the specific track. The trackstep then cannot advance until all of the patterns have finished playing.

For the patterns that are on, one pattern command is processed per interrupt. In the case that the pattern specifies a note/macro, the pattern controller goes into a loop to process the macro until the macro specifies a wait which will cause it to hold until the next interrupt.

With the new system, pattern loading and macro loading is handled by separate functions. With this it is possible to independently load patterns or macros for testing purposes. I’m using this to my advantage and have designed a function to individually test macros for playback as is done in the original TFMX editor itself. Since I have been focusing on resolving the issues with the update cycles and timing system which have resulted in a total overhaul, I have not been able to successfully implement all the effects since they are inseparably tied to the timing system. With the test macro functionality in place, I will be able to finish implementing the effects and easily test them by playing back each of the Monkey Island macros.
As for the external interface to interact with; as stated, you simply make calls to individual load the data and sample files (these functions will be changed to accept parameters). You then simply call playSong to play one of the individual tracks. The track will automatically stop when complete or you can call a stop function at anytime to terminate the song prematurely. With these simple functions in place, it will be easy to add code to Monkey Island engine to playback TFMX audio. Hopefully, once the remaining effects are in place, TFMX audio will be ready for prime time. I hope to have them all in place over the next week and then proceed with the final step to linking to the Monkey Island engine.