March Development Report

As was mentioned in the February development report, we've been working on getting the Orange Box games based on the new Source engine working for our next major Cedega release - that encompasses Team Fortress 2, Portal, and Half Life 2: Episode 2. We've wrapped up the initial work necessary to get them running and have moved on to playability issues. Sound turned out to be an problem, with two different issues showing up: using the OSS backend resulted in a crash on startup, and using any sound backend in-game sometimes ended up with looping sounds. The OSS issue turned out to be due to an architectural difference between our OSS and ALSA implementations related to the limitations of the OSS interface. Our implementation has been suitably revamped. These games turned out to be the beneficiaries of a Cider title, which was under development at the same time, and had similar sound issues. With those issues fixed, the sound looping bug in the Source games appears to have been dealt with.

The non-graphical APIs used by games tend not to vary too widely given games' heavy focus on graphics. However, we do periodically come across new APIs or variants of existing ones. A recent variant that we came across tests the existence of directories. By far the most common way to do this test in Win32 is via the GetFileAttributes or GetFileAttributesEx functions. However, it is also possible to "open" the directory via the CreateFile function if you specify the FILE_FLAG_BACKUP_SEMANTICS - so named because the usual use for this functionality is for backing up a directory and its contents. Since this functionality was being used as an existence test for directories in a title we were looking at recently, we've gone ahead and implemented the needed pieces to make this more expensive alternative to GetFileAttributes work.

In last month's development report we told you about one of the graphics features for which we've been adding support, Mul tiple Render Targets (MRTs). This feature allows games to render to multiple buffers in a single pass, thus simplifying or eliminating multiple passes to achieve a particular effect. Many games will use this feature, if available, to increase performance, and in some cases they will add additional graphical effects due to the lessened performance cost. The initial cut at this feature has been completed and integrated. As is to be expected from a major graphical change, there has been some fall-out due to games using the feature in an unexpected manner, due to driver issues and due to some games going down different rendering paths now that this feature is exposed. Several such issues have been resolved and we're aiming to clear out any remaining regressions from this change on short order.

A variety of other graphics work took place this month on several fronts, including:

• a few issues with our point sprite implementation (used by some game engines for rendering particles) have been identified and dealt with
• support was added for anti-aliased lines
&bull a memory corruption bug affecting several games including Far Cry was tracked down to our vertex buffer implementation and fixed

Some games that use DirectX 8 and the d3dx8 library use a couple of undocumented APIs for validating vertex and pixel shaders. Work has been done on those functions so that they better match what the application expects, thus allowing more of that class of games to run.

One area that doesn't tend to get a lot of attention when focusing on games is printing. Some titles do support it however, and in some (particularly more casual games), printing is a core piece of functionality. A title under development required printing support, so some effort went into this. Since both Linux and the Mac use the CUPS printing system, both benefited from that work. One hitch on the Linux side is that we'll need to update our build system to a less ancient distribution - we've typically built on older distributions to ensure wider compatibility, but it has reached a point that too much functionality is unavailable without much shoe-horning. This is scheduled to occur in the near future.

Finally, one of the shortcomings of Cedega that has limited the games that can be installed has been its lack of MSI (Microsoft Installer) support. Some initial work had been done a while ago to integrate WineHQ's MSI support, but that hadn't been completed or polished. That work is now ongoing, and the current Steam installer as well as the installer for Command & Conquer 3 are now largely working. One consequence of the addition of MSI support is that, paradoxically, a few of our supported games no longer install properly. This is because they are actually MSI installers but also packaged the actual MSI runtime as an executable. Since they detect that MSI is already available, they no longer run the executable and instead directly use our MSI implementation. In some cases, either the MSI implementation or some of our functionality supporting it has some issues. We are putting a push on resolving those, and any fixes we do to MSI are being submitted to WineHQ for them to integrate into their implementation as well.

Mark Adams
Development Manager
TransGaming Technologies
Broadening The Playing Field