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..

Leave a Reply

Your email address will not be published. Required fields are marked *