GSoC 2020

Trying some .X loading

Wintermute3D offers the possibility to load in and display 3d models from .X files. For this it relies on functionality offered by the D3DX helper library, which parses in the data into an intermediate data structure. Wme then puts the data from there into it’s own data structure, which actually closely resembles the .X file format, meaning that essentially for every non-trivial data type there is a class in the engine code. Now although these classes are portable, which is very convenient, the loader itself is missing and has to be implemented from scratch.

So the first thing I did at the beginning of this week was to import the usable code from Wme3D into ResidualVM. This took some time, but now almost all importing of necessary or potentially useful code is already done. After that I started to work on a parser for the .X file format. Originally the plan was to base the parser on the Assimp library, but after some more research on the format, I thought, that implementing a recursive descent parser from scratch might be just as good as an option. So that’s what I did. Now at the moment, several key parts are still missing, but the essential structure is there and I am able to load in some data in display in “some” way onto screen, like this:

In front of the first door, there is a 3d model of what is supposed to be Trinity from the movie Matrix. As one can see, it’s somewhat displaced in mid air. Also the scene geometry is messed up, as can be seen by comparing above image to the one from my last post. But hey, what can you hope for..

One thing that I have to change about the whole .X parsing stuff is the handling of commas and semicolons. By design, .X files like semicolons, everywhere, and the code shows this very explicitly at the moment.

During all of this work I also learned the hard, that the override keyword can be very useful (if you use it). Some of the classes, that I imported, where supposed to override certain virtual member functions. But the function signatures of the base classes had changed when they where imported into ScummVM and so nothing was overridden. And then I wondered, why the imported code wasn’t called. Another moral of this story could be though, that checking compiler warnings, at least sometimes and also keeping them minimal would be a good idea..

GSoC 2020

Coding starts, what has happened so far?

The coding phase of this year’s GSoC will begin this week. What has happened so far on the porting of Wintermute3D into ResidualVM. Well, first I started learning a little about OpenGL 2.1.Having done some Direct3D 9 in the past, a lot of the concepts were familiar to me, but nevertheless a different API is a different API. I tried out some loading of .X files as well via the assimp library, just to get a feeling for what would expect me since .X files are a big part of the project.

One aspect of the project is to load in data from an .X file. My first plan was to base a parser on assimp, taking out the code and reusing parts of it. But I realized after starting to write a lexer for the .X format that writing a recursive descent parser myself as well is not that difficult and might be even more straight forward. At the moment I am more concerned about displaying and animating the data, which has a lot of room for little, hard to find, errors, although I can reuse a lot of code here from the original code base.

As an additional exercise, I took the existing renderer for the Wintermute port of ScummVM, after importing the code into my ResidualVM fork and implemented a simple texture renderer based on it.

After that, I got a little bit more ambitious and decided to go for an actual OpenGL based renderer for the 2d graphics part, which would also be the foundation for the rest of the project. In the beginning things were buggy, partly due to miscalculations of coordinates but also due to the fact that Direct3D offers something called transformed vertices, which bypass the transformation pipeline. It took me some time to realize this as I was searching the Wintermute code base for the part where actual 2d rendering to the viewport is activated. The catch is that this is done by setting a specific vertex format. Now OpenGL has no direct equivalent for this but one can set an orthographic projection via glOrtho to archieve the same effect.

Here is a screenshot showing a temporary state (this is from the Wintermute 2d demo). It was taken after I discovered how to setup 2d rendering onto the viewport. As one can see, the color key is still there and the sprites are somewhat displaced, which is due to the fact the Direct3D and OpenGL differ in what corner of the viewport has coordinates (0, 0). These things have been fixed since then. What is still missing on the picture above are two more sprites displaying two people. This is because I didn’t yet implement the necessary functions and I might postpone this until much later since complete support for 2d graphics is not the goal of this project.

I also wanted to do some 3d rendering, so I took some of the Wintermute3D code for the scene geometry and reintegrated it into the ScummVM Wintermute port. To display the scene geometry (which is actually supposed to be invisible and only the for lightning and shadows as well as path finding), I needed to implemented a .3ds loader. Now fortunately the .3ds format is not so complicated and Wintermute3D even has a .3ds loader which I used for comparison. On the other hand, I still had enough pointer arithmetic bugs in the beginning but I like this kind of stuff, so it was fine. Displaying the data correctly was again another story, I had some fights with camera and projections matrices and had to find out the hard way, that the .3ds format is using a right-handed coordinate system where the z axis is pointing upwards. Wintermute3D is just exchanging the the y and x coordinates, but this also changes handedness (a great illustration that switching rows in a matrix negates the sign of the determinant!) and thus does not work for OpenGL, one has also to negate the z coordinate (or y coordinate, from the .3ds perspective). After taking this into account, I got the following result:

This is from the Wintermute 3D demo. The background is just a two-dimensional texture, the (again, usually hidden) geometry (here visible) is actually 3d though, as one can see.

So this is essentially the current state. Simple 2d and 3d rendering (with the necessary state switching) as well as loading of simple .3ds files. There are plenty of details missing here, though, for example text is not rendered correctly yet. Nevertheless, I will postpone this somewhat later and instead spent the next two weeks or so on getting rudimentary loading and displaying of .X models done. This is mainly due to the fact that this is a big chunk of work which I would like to get done quickly so that I am left with smaller, more manageable pieces. If possible, I would like to add animations as well to this during this time, but after my experience with the .3ds models I am very concerned about potential coordinate system bugs and expect a lot of debugging time for this.

GSoC 2020

ResidualVM GSoC 2020 Introduction

Hello guys, my name is Gunnar and I am one of the fortunate students who got accepted into this year’s GSoC to work on the ResidualVM project. Essentially my goal will be to port the missing 3d graphics parts of the Wintermute engine which are missing in the existing Wintermute port in ScummVM.

Why do I want to do this? Well, I really enjoy programming, game programming in particular, although I never worked out an actual game, mainly for the reason that I shunned away from all the asset creation stuff, which I do not enjoy at all. But with this project this will be irrelevant as the assets are already there and only the code has to be written, very much to my own taste. Also I like the idea of making games run on Linux (or non Windows platforms in general) and I also start to really enjoy the idea of open source software.

Some more personal information. I am 26 years old and currently a student at the university of M√ľnster in Germany. My subjects are Mathematics and Computer Science, although I focused on Mathematics in the past few years. My programming activities consisted mainly in student assistant jobs but now I am looking forward to open source development.

I will leave this as is for now. Until the start of coding on first June I will mainly prepare myself for the task and post some updates here.