May Development Report

As mentioned in an earlier development report, we've been continuing to work on MSI (Microsoft Installer) support. We now have Command & Conquer 3 installing properly, which has been the main impediment to being able to support this game under Cedega. There is some additional work to be done on the patcher, and that is in progress. The Steam and Orange Box installers largely work, although there is a remaining stability issue being tracked down. We have also been working on fixing the installers for games we currently support but which broke once we started advertising MSI support. In particular, Command & Conquer: Generals once again installs.

Many games need to be able to time high speed events. EVE Online is no exception to this rule - it makes heavy use of the GetTickCount() and QueryPerformanceCounter() functions to do a lot of its frame timing. The problem with our implementations was that they could actually go back in time if the system clock were adjusted during gameplay (ie: via ntp). EVE would detect this time warp as a counter wrap-around and converted it into an astronomically large time period that the rendering engine couldn't handle. Our solution was to make sure that the time values returned by these two functions were always monotonically increasing (until an actual wrap-around occurred of course). This was done by internally detecting the time warps and adjusting our epoch value to compensate for it. This resulted in the same time value being returned twice so it appeared to the game that no time had passed. Because of this work, EVE's rendering engine and any others which are sensitive to this issue can now survive moderate system clock adjustments.

An upcoming title we are working on has the capability of dragging files onto the game window to load objects and characters. Although we already had extensive support for a couple variations of drag & drop, we did not handle the one case this game wanted to use. In particular, it wanted to use the RegisterDragDrop() function to set up the game window as a target-only drag & drop interface. We implemented this by intercepting the WM_DROPFILES message and dispatching the drop event to the registered target object. As a result, image files can be dragged from the Linux desktop into the game and used seamlessly.

One of the big differences between Shader Model 3.0 and previous shader models is in how vertex and pixel shaders link together, and we've made some substantial progress in our support for this over the last month.

In previous shader models, a vertex shader wrote its results to a standard set of outputs, each of which had a directly corresponding input on the pixel shader side. These outputs/inputs were named by role, such as texture coordinates, colors, position, fog, etc. By writing to a given output on the vertex shader side, you were guaranteed to have the interpolated results based on that value fed in with the same named input on the pixel shader side. This model matches up well with what the ARB_fragment_program and ARB_vertex_program extensions have provided, as well as with some basic built-in functionality that the GL Shading Language provides.

Things got rearranged a bit with the introduction of Shader Model 3.0. Now there's a single group of numbered outputs for vertex shaders and a single group of numbered inputs for pixel shaders. The thing is, they no longer match up directly. To match up the vertex shader outputs with the pixel shader inputs, the linker needs to look at the semantics, which are like little name tags that each input/output has to wear. These semantics take the form of texture coordinates, colors, position, fog, etc.--so in a way, it's a lot like before. But at the same time, things have now become much more complicated and nuanced. For instance, an input/output (each of which is really four floats) might employ multiple semantics; a pixel shader might not define all the same semantics that the vertex shader does, or it may choose to drop some of the floats from some semantics; and input/outputs tagged with the color semantic are no longer restricted to values between 0 and 1.

In the past month, we've made great strides in this area, introducing a full solution to this problem targeting the GL Shading Language. The code has been designed with the twin goals of performance and the potential to target mixed mode (i.e., the ARB program extensions) in the future, if need be. We also support a lot of corner cases as well, although we still have a number of these we will be looking to shore up in the coming months. The end result will be many games looking a lot spiffier.

Mark Adams
Development Manager
TransGaming Technologies
Broadening The Playing Field