gunnar's GSoC blog

With the shader renderer being stable and Alpha Polaris looking fine, I was curious about some other WME games. Specifically, I took a more detailed look at Mental Repair (which is free and interestingly, a result of a Bachelor Thesis) and Act of Murder 1: FBI Confidental.

Both games turned out to be buggy, especially Act of Murder 1, mostly due to missing features or details which had been skipped so far, although it also seems, that at least spot lights are not setup correctly, too.

Initial issues in Mental Repair are fixed though and soon I will attempt a complete playthrough, just to see what happens. Act of Murder 1 will require much more work it seems, it has special viewport settings, meaning that 3d content is only rendered into a part of the window/screen and this causes all kinds of problems. Also lights seem to be incorrect here, but lighting has to be worked on anyways. Here is a screenshot:

This is with adjusted spot light settings, so that the models are really light up. I still have to figure out the actual values out. More issues are the shadow being cropped for some reason (the model itself does not suffer from this) and the pathfinding is not really working either, meaning you can just walk trough the chair for example.

So last time we were at a point were the engine port works with OpenGL ES 2 shaders. One reason to implement this was actually to find out what a proper base interface for the rendering part would look like. This interface should abstract away the differences between the fixed and programmable pipeline APIs being used and also at least allow for a potential software renderer based on TinyGL.

The next step was thus to reorganize the current renderer code in a somewhat more proper way and also move some rendering API calls into more suited spots like the renderer classes for example. Also the old OpenGL matrix stack is not used anymore, since it was kind of unnecessary and there is a clear boundary now on which matrices are going to be transposed so that they can be passed to OpenGL (the boundary being the renderer interface actually).

One more thing that has happened is the implementation of a binary .X file lexer. Originally I though that this step would be straightforward, but actually the grammar for binary .X files is slightly different to save some space. Instead of writing a new parser I decided to hack the lexer in such a way (and also introduced some new functions for it) that the parser could stay essentially the same.

Here is a screenshot of “On the track of dinosaurs” demo, which has a binary. X file:

There are some oddities with this file, for example, it has less normal vectors than actual vertices. This might explain the dark spots because no or wrong normal vectors means messed up lighting. Also the animation data is contained in an additional file and support for loading of such a file is still missing.

Now we can render our WME games even with shaders. The most work was actually related to setting up the surrounding code and not so much the actual shaders (minus the one which is responsible for rendering .X models). At the moment, things are somewhat unorganized however and the current code should be refactored, interfaces improved and common code factored out. I would claim that at the moment one can see the fact that WME was designed for the old fixed function pipeline and that the addition of the shader renderer is not completely straight forward. In contrast changing from Direct3D to OpenGL was easier, the only real change that I made was using the OpenGL matrix stack, which now turned out to perhaps been the wrong direction. Well, it can be reimplemented (and is so at the moment), but the old WME code didn’t rely on it either, so I might change this back.

I hoped that lighting done by shaders would produce the same results as the original code but this is not the case.

Let me just assure you that Rune is not supposed to look like he is almost getting sick. Apart from that though, things seem to look just fine.

Ok, what’s so special about the following picture:

Well, nothing, except that the scene was rendered with OpenGL shaders instead of the old fixed function pipeline. Which in this case (2d graphics) was not the biggest change, essentially only the 2d projection matrix has to be setup for the shader. 3d graphics will require more work, though. Also some refactoring will be necessary, some of which has already happened. For example, there is a 3d renderer interface class now with two implementations, which can be selected from the ResidualVM menu (a third one, based on TinyGL, is supposed to follow at some point in the future).

For some reason, when walking into the house and also when leaving it, during the animation the cursor becomes completely black, but only with the shader renderer. Now I am not too unhappy about this, at least it shows that the two renderers indeed operate differently.

Speaking of different behavior, the shader renderer might also be helpful when going back to lighting, since currently, the fixed function renderer does not give the same results as the original Wintermute Engine. If the shader renderer can reproduce WME lighting, than something would be wrong with the fixed function settings. If, on the other hand, shader and fixed function renderer produce the same results, something will be wrong with the rest of the code, possible normal vectors. If all three implementations are different, than it’s kitchen sink, though.

Another major step is done, rendering shadow volumes of 3d objects:

The shadow looks beautiful, I have to say, stencil shadows are great. Also Rune does not appear to be floating over the ground anymore in this scene.

WME has some more shadow techniques (looks like it got real time shadow mapping, if the graphics card supports it), but they don’t seem to be too relevant, so it might be better to postpone their porting until a later point.

One thing which is bugging me is the fact that lightning does still not give the same results everywhere compared to WME. But I am going to accept this for now. Now is the time to add some more missing stuff and cleanup the existing code.

So, saving and loading seems to be fully functional now, including compability with ScummVM save files. The last bug was caused by a mistake during code import from the original Wintermute Engine. I had similar bugs on multiple occasions, which is rather annoying, as these mistakes should be unnecessary, but so is life I guess. Next thing on the menu are lights and shadows, to make the visual output more enjoyable, for example:

The faces in particular look much more round and plastic than before. Now what I don’t like so much is that at this spot Rune should appear a little bit darker but I am not sure what is wrong here.

This is my new favourite:

No textures, but normal vectors are being rendered, just so that I could check if they are correct. Now in this picture they are actually not correct, which might be hard to see, but if you want to, you take a closer look at the chest for example. There a vertices with the same position but different normal vectors, which means that these vertices will receive light with different intensity. This will create more distinct edges which will be desireable in certain situations, but not here. The first picture by the way does not have this issue, hence the smooth skin.

The problem was created in the first place because I decided to recalculate the normals during animation updates (I am not 100% sure anymore if this is really needed, although it probably should be). But different vertices (even if they have the same position) mean different normals, as long as you don’t specify, which vertices should get the same normals. Since this information does not seem to be contained in the .X files, instead now I just update the normals directly via the bone transforms.

We are now able to select 3d objects by mouse clicks (2d object selection was already part of the ScummVM Wintermute port). Take a look at the following screenshot:

Essentially what happens is that we have a bounding rectangle (constructed from a bounding box) for our model, which is added to a list. Every frame the list is traversed. If the mouse coordinates land in one of the rectangles, a more precise test is performed. In case of our model this means that we send a ray into the scene and check if it hits one of the triangles of the model. If so, the model becomes the active object, which means it can be selected by a mouse click.