Month: May 2008

Upcoming Tasks

So with coding official underway, it might be wise to take some time to organize some upcoming tasks and milestones. For now, I have a handful of goals which are critical to developing a functional TFMX replayer.

  • Complete further analysis of the TFMX file structure. I need to specifically look at the structure of pattern and macro data as well as the trackstep to interpret their function and commands. This is already underway. For now, focus is on the trackstep and pattern data with the macro implementation being ignored until later.
  • Develop structure in main() function for launching and experimenting with PAULA audio objects. This will later transform to a launcher for testing TFMX objects.
  • Design class and refine class structure for TFMX objects with basic function prototypes and member data.
  • Begin initial code to open TFMX files, perform some basic checks, and initialize necessary tables read from the TFMX file.

As of right now, I’m working through interpretation of the pattern data functions. This is a little bit tricky as the documentation available is not always clear and in some cases is just wrong. I’ve reworked through some of the other existing players to try to patch together the necessary information.

Monkey Island Sound Files Redux

There is a functional WIN32 console player available which functions with the Monkey Island sound data files. Remember, the full sound data files are available in the Monkey Island demo. With this console player, you can extract useful info from the data files. You simply need to run tfmxplay with the -i flag. Of course, you can actually play them also and individually select each song to track to play.

>tfmxplay -i mdat.MonkeyIsland
4 voice TFMX module: mdat.MonkeyIsland
Date : 02.01.91
Time : 13:33

49 tracksteps at 0×0800
128 patterns at 0×0400
128 macros at 0×0600

Song 0: start 800 end 900 tempo 202
Song 1: start 400 end 500 tempo 144
Song 2: start 600 end 700 tempo 202
Song 3: start a00 end d00 tempo 144
Song 4: start 2800 end 2d00 tempo 176
Song 5: start 1100 end 1200 tempo 172
Song 6: start 1300 end 1400 tempo 98
Song 7: start 1500 end 1600 tempo 200
Song 8: start 1700 end 1800 tempo 88
Song 9: start 1900 end 1a00 tempo 104
Song 10: start 1b00 end 1c00 tempo 210
Song 11: start 1d00 end 1e00 tempo 126
Song 12: start 1f00 end 2000 tempo 90
Song 13: start 2100 end 2200 tempo 71
Song 14: start 2300 end 2400 tempo 142
Song 15: start 2500 end 2600 tempo 148
Song 16: start 2e00 end 2e00 tempo 0
Song 17: start 100 end 300 tempo 5
Song 18: start 2f00 end 2f00 tempo 4
Song 19: start 3000 end 3000 tempo 5
Song 29: start 2900 end 2a00 tempo 176
Song 30: start 2f00 end 2f00 tempo 4
Song 31: start ff01 end ff01 tempo 0

Subversion Mistakes

In an effort to get my ScummVM branch to compile in Visual Studio, I copied some newer project files updated and maintained by other developers who use Visual Studio as well. These updated project files fixed some compilation bugs and warnings. However, the updated project made reference to some non-existent files in my directory structure, specifically in the /engines/gob/ folder. So my solution was to copy the updated code from /engines/gob/ directory of the main trunk to my branch and then update. The updates ending up affecting the entire folder and committing 47 changed files in /engines/gob to my branch. See the update history here. It turns out this is a poor method for taking updates from the trunk. The updates now seem like I was the one committing the code changes which not only messes with the revision history, but also makes it more difficult to re-merge my branch back to the main trunk when the project is completed. This was a silly mistake which will end up causing some trouble which will require some manual fixing.

In order to properly manage updates from the trunk and implement them in my branch, the svnmerge.py tool is necessary. The tool and directions for use can be found here. This tool, when installed in your working directory, will properly manage updates from the trunk. It is also helpful when merging branches back to the trunk.

Development Platform

I’ve decided to settle on Microsoft Visual Studio 2008 Professional as my development platform of choice for this project. I have not made the move to Linux where there are more free tools available by choice since adapting to Linux will take some valuable time out my schedule. Sticking strictly to Windows where I have the most experience and using Visual Studio, which I also use for work, seems like the best idea. The great thing is Microsoft is offering a whole boatload of expensive development software to students for free, including Visual Studio 2008. This is probably a great opportunity for other GSOC students out there so if you didn’t already know, check out Microsoft DreamSpark.

ScummVM is hosted on SourceForge.net like many other open-source projects and uses Subversion for version control. My SourceForge username is marwanhilmi and I’ve been attached to the ScummVM project. You can view the repositories here. A branch was created for my work on the project named “gsoc2008-tfmx” which you can view here.

In order to handle code updates and commits with Subversion, I’ve opted to use TortoiseSVN client for Windows. You can find it here. It is very slick and interfaces directly into Windows right-click context menus. You can update code and make commits with a couple of clicks.

If you are not familiar with Subversion, there is a great O’Reilly book available for free here.

Compiling my ScummVM branch with Visual Studio proved to be a little tricky initially. Fortunately, some of the other ScummVM developers also use Visual Studio and some fixes and updates were already committed to the main trunk. After downloading the new VC-Project files and some other updates, I was able to properly compile and run the code. Some information regarding compiling ScummVM in Visual Studio can be found here.

Monkey Island Sound Files

In order to implement proper support for the AMIGA version of Monkey Island, the TFMX interpreter developed obviously needs to function correctly with Monkey Island’s data files. In turns out, after some poking around, that the demo version of Monkey Island has the complete audio track in it. You can obtain a copy of the demo here. The demo is in .lzh format, a disc image format for the AMIGA. You can actually extract the files from the demo using WinRAR or other command line utilities if you are on Linux. The audio files are music.dat and sample.dat contained in the Rooms sub-directory. Comparing these files to the files from the actual full AMIGA version of Monkey Island shows they are identical. The files from the full version have the same structure, headers, and size.

Demo Files
sample.dat 179,380 bytes
music.dat 46,704 bytes

Full Version Files
sample.dat 179,380 bytes
music.dat 46,704 bytes

If have a copy of the full version you can check them and compare for yourself.

Calm Before the Storm

Time is moving really quickly and the official start of coding is looming ever closer. Progress on my research and planning phase is moving as expected. Thanks to the friendly visitor Triton, I’ve obtained a restructured version of the tfmx-play code. The tfmx-play module floating out there was functional but a nightmare in terms of readability and reusability. This restructured version definitely helps out so much thanks to Triton again. I’ve also spent some time poking around with the PAULA emulator in order to gain a better understanding of the information it requires in order to process audio.

I plan to spend time over the weekend experimenting with the PAULA emulator and the existing audio classes. Big updates to the site are coming over the weekend as well so stay tuned.