Month: July 2020

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.