Author: Administrator

Wow, two months passed since the last post; real life took me some time (as this did – sounds great! -), but I’m now getting into development again.
Anyway, here’s the usual list of notable improvements (which are a lot):

• Residual was renamed to ResidualVM, to match up with ScummVM (and because residual.org was already taken ;)).
• We have a new site, www.residualvm.org, and the forum was moved there.
• Following the rename, we are now on #residualvm on freenode, and the code is at www.github.com/residualvm/residualvm.

• We have a New engine! Myst3 is now supported, thanks to the work by Bastien (aka bgK). All hail to him! (I’m not into it, so don’t be afraid if you don’t hear of updates of it from me)
• Remember the last post, where I explained how to fix a bug in Grim’s data? Well, you can forget that, since Andrea (aka YakBizzarro) added a hot-patching system. No need to fiddle the data anymore, now ResidualVM’s code does the magic all by itself. Along with that other bugs in the scripts have been fixed.
• Similar to the entry above, now the official 1.01 patch is loaded directly as a .exe. You don’t need to extract it anymore, it will be loaded by ResidualVM as-is.
• TinyGL (the software renderer) now supports any color-mode and color depth.

These are the main things, but around them there are a terrific number of littler improvements and bug fixes.

I took this graph from Ohloh. It shows the number of committers over time. You can clearly see the boost that happened recently, and that imho is the most notable improvement the project had.

Stay tuned!

More than a month has passed since the last (and first) entry of this series. I’ve been a little busy with other things, but that doesn’t mean Residual ResidualVM development was paused.
First of all, two new contributors stepped in to help the development:

• DarthJDG added antialiasing support. Add to your Residual ResidualVM config file the line antialiasing=$samples, with $samples equal to 0 (that is, no antialiasing), 2, 4, or whatever your graphics card supports, and enjoy the improved and smooth graphics!
• juj worked hard on the bugs 31 and 247, regarding wrong head orientations, and made a pull request that fixes them. It is not in master yet, since there are some things to improve first, but the main code is there!

Aside the usual bugfixing in the Residual ResidualVM code I looked into a bug in the game scripts, a bug that existed since the Release in 1998 and that even Tim Schafer didn’t know of! This bug prevent(ed) a critical dialog with Domino at the end of the world to play, a dialog that explains the main plot!
I’ve explained what’s the problem behind the bug in the forum, with a possible fix. However, somaen recently added in Residual ResidualVM the support for a new lab file, called datausr.lab, which takes precendence over the others. This allows for a better fix, not needing anymore to replace data000.lab. These are the needed steps:

1. Compile the tools mklab, delua and unlab from residualvm-tools;
2. Unlab data000.lab to a directory and delua the file dlg_dom2.lua;
3. Copy the “deluaed” file to a new directory datausr, keeping its name dlg_dom2.lua;
4. Modify its first line to CheckFirstTime(“dlg_dom2.lua”);
5. Create datausr.lab from the directory using mklab and put it where you have the other lab files;

Now when you run Grim you should see a dialog like this:

Now click OK and you’re up and ready to hear from Dom’s words his evil plans.

The residualvm-tools repository was born on April, 7th this year. From the very first moment I felt its build system was broken, mainly for these three reasons:

1. to build a specific tool you must run “make tools/foo”. The repo is called residualvm-tools, there should be no need to specify “tools” in the make call too;
2. there isn’t a single line of Makefile code shared between the different tool targets;
3. each submodule of tools/, like tools/lua/module.mk, needs to be added in Makefile.common. I’d like a way to set it up into tools/module.mk, with a parent-child relationship.

So some days ago I decided to try to improve it a bit, even though I never wrote a single line of a Makefile.

My first try was to work on rules.mk: I modified a bit the code that created a target from the value of TOOL_EXECUTABLE and of some other variables. After some trial and error I came up with a piece of code that allowed me to put in tools/module.mk, for each tool, something like this:

TOOL_EXECUTABLE := unlab
MODULE_OBJS := unlab.o
include $(srcdir)/rules.mk

TOOL_EXECUTABLE := vima
MODULE_OBJS := vima.o
include $(srcdir)/rules.mk

....

Quite ugly, but still better than before.

Then I started working on 3. Long story short, I couldn’t come up with an acceptable solution.

Then an heretic thought passed through my mind: CMake!
I really like the add_executable and add_subdirectory functions of CMake, but I know that porting to CMake would require a big effort, since it doesn’t work out of the box on all the platforms configure currently supports.
So I started thinking: configure works perfectly, I just need a way to confortably generate a bit of Makefile code. configure is an sh script, why not just use sh?

So I wrote a script, makegen, with the functions add_executable and add_subdirectory.

add_subdirectory() {
    MODULE="$MODULE/$1"
    . $srcdir/$MODULE/module.mg
    MODULE="${MODULE%/$1}"
}

add_executable() {
    echo -n "$1_SOURCES := " >> $builddir/Makefile.modules
    for f in $2; do
        echo -n "$MODULE/$f " >> $builddir/Makefile.modules
    done
    echo >> $builddir/Makefile.modules

    echo -e \
"build: $1
$1_DIRS := \$(sort \$(dir \$($1_SOURCES)))
$1_dirs:
    \$(QUIET)\$(MKDIR) \$($1_DIRS)
$1: $1_dirs \$($1_SOURCES)
    \$(QUIET)\$(MKDIR) \$(DEPDIR)
    \$(QUIET_CXX)\$(CXX) \$(LDFLAGS) $3 \$(DEFINES) -I. -I\$(srcdir) \
    \$(filter %.cpp %.o, $+) -o \$@\$(EXEEXT)
EXECUTABLES += $1\$(EXEEXT)
clean: clean/$1
clean/$1:
    \$(QUIET)\$(RM) \$($1_SOURCES) $1
    \$(RMDIR) \$($1_DIRS) \n" >> $builddir/Makefile.modules
}

This script is called from configure and it simply generates a file Makefile.modules with the targets for the tools.

Now, adding a new tool is simply a matter of adding in tools/module.mg

add_executable toolname "toolname.o foo.o bar.o"

You’ll then be able to call make toolname.

This is not finished and still experimental, and I can’t know if it will ever be actually used, but I would like to hear some thoughts.

This is the first installment of a periodic (I don’t know the frequency yet, could be weekly or monthly, or a mixture) series on what happens around Residual ResidualVM.

First of all, if you don’t know it already, there has been some ferment recently around a project born on the forums aimed at improving the graphics quality of Grim Fandango, both improving texture quality, models and even making Grim widescreen!
You can read more about this on Johnny’s blog.

As regards the code, Einar (aka somaen) refactored the Smush code, making it more clean and maintainable. I finally implemented collision handling between actors when walking to a point. No more Manny walking through the signpost or Velasco or Glottis! Another worthy point, the savegame format changed, so if you had some saves made before the 3rd, say bye bye to them.
(Or don’t update Residual ResidualVM.)

That’s it for now, stay tuned for the next updates!

Welcome to my shiny new blog!

Some of you may already know me, I’m a Residual ResidualVM developer since some months ago and on this blog I’ll update you of the steps forward of that cute piece of code.

For those who don’t know what i’m talking about, Residual ResidualVM is a sister project of ScummVM, thought for 3D adventure games. Currently it supports Grim Fandango only (which is completable), with Escape from Monkey Island starting to gain steam and engines for Myst3 and The longest Journey being worked on outside of the main tree.

But you can read more on Residual ResidualVM’s site, wiki and forum.

Feel free to test it, report any bug and contribute to it!