Author: Administrator

A picture says more than a thousand words

…which should put this blog entry far beyond 10 000 words. There has been a bit of progress with the Wintermute-engine, preliminary support for graphics, sound and I/O is in place, but it is far from perfect, or finished in any way, shape or form.

Right now, the sound system only allows playback of OGG-files, and it only does Play() for them, which was a rather simply task to add in, simply to verify that the sound system still works after having been stripped down from WinterMute Lite, either way no further work is planned on that part for atleast a few weeks.
I also added in some quick hacks to make the engine draw inside ScummVM, right now this is done in 24 bit hardcoded blitting, and was mainly done to see what had to be done. At this point it might be worth noting the work that was done on WME Lite prior to attempting to merge it into the ScummVM-tree as a branch. I started off by forking the original WME-Lite repos onto Github, then I went on to strip out all the dependencies (BASS, Boost, SDL2), as well as removing as much as possible of the “forbidden”-bits (ScummVM doesn’t allow direct usage of the C-APIs for file-accesses and random number generation among other things). As I went on, i ported over as much as possible of the ScummVM common code to WME Lite, until I reached the point where I might as well move the WME source over into my ScummVM-fork.

One of the things I did quite early, was to try to use the ScummVM-image loaders, as opposed to the SDL2-code that was used already in WME Lite, I made that kind of work, but transparency proved problematic for now. I picked the game Dirty Split as a test case for the moment, here is how it looks:

This is how the inventory in Dirty Split looks in the original prebuilt WME Lite
… and this is how it looks in my modified WME Lite-version, that uses the ScummVM image loader.
Now, for the first ever image of a Wintermute-game running inside ScummVM:
Yup, this is ScummVM, although it isn’t really obvious from the headline. Notice how the fence is wrong, and the transparency is off in all sorts of different ways.

The reason for all those interesting artifacts, is mainly that I only added a quick-fix for the colour-keyed transparency, but didn’t do anything for the alpha-channel stuff yet. Keen eyes might also notice that the character is a lot bigger in ScummVM, although this is the very same scene, with no movement done yet. This is another case of missing features, right now any bitmap that asks to be drawn, is drawn at it’s full size, no matter what it actually says about the wanted size. This gives a few rather odd behaviours at the moment, as for instance, walking away from the screen isn’t really obvious:

This is how walking up to the door looks in WME Lite (with a few of my modifications)
… and this is how it looks in ScummVM at the moment.

Clearly, the model’s need to scale appropriately, but, atleast input works well enough to get the character to move over there. The action-menu for Dirty Split reveals a few more of the transparency-quirks:

in ScummVM
in WME Lite (with my modifications)
I’ll be looking into solving these issues as I implement a more proper drawing-solution in the weeks to come.
Oh well, that’s about it for now, I’m off to do my exams, so what better way to end of, than to show how the three variations of the game look when you try to close it? Yes, there are a few minor differencies her, as I didn’t go through the menu in ScummVM, but simply Ctrl-C-ed the terminal session.
ScummVM
Modified WME Lite
Original WME Lite

 

A beginning

Since I started thinking about approaching this task, I’ve been doing a little work on the WME Lite code base. I originally forked that repos, and started removing the bits I knew that wouldn’t work with ScummVM, which mainly meant stubbing all the dependencies away (Boost, BASS, SDL2), and getting to grips with where STL was used (as ScummVM doesn’t allow me to use those).

I then did a bit of “reverse-porting”, copying over pieces of ScummVM to that repos, so that I could start replacing pieces of WME-code that depended on things that aren’t available in ScummVM, with the proper ScummVM-solutions. This worked up until a certain point, namely getting files to actually load (that would require copying over LARGE amounts of ScummVM-code). At this point I’d gotten to know the WME-codebase a bit better, and also untangled a bit of the header-dependencies that was there (which was usefull, to avoid having to copy the ENTIRE codebase in one go), to the point that I could start copying the files over to a branch in my ScummVM-fork.

This led to a day or so of resolving problems relating to common/forbidden.h (I hadn’t purged all the STL/FILE-related pieces of code, since the main reason for moving on from a fork of WME, to a fork of ScummVM, was to get files loading). Additionally I also had to follow the “HOWTO: Engines”  guide in the ScummVM-Wiki, to get the connections correct with the rest of ScummVM

But, in the end, I managed to atleast get a repos that compiles, and links in-tree. Right now, it even detects the game data, and should be just a few hours away from being able to get the scripts out of the data files, to start running the main loop of the engine.

This puts me quite a bit into stuff that was planned a bit further down the road in my GSoC-timeline, but sometimes things tend to happen in rather different orders than what one actually plans, there is still work to be done for what was planned as the first week’s work (Refactoring), but happily, I’ve gotten some help from Sev with automated renaming of variables, which should save me a day or two of manual labour. (Combined with some application of astyle, this atleast gets me of the start line for making the code base follow the ScummVM code-formatting guidelines).

In closing:
I might not be getting too much work into the next few weeks, as I have exams coming up, but I do plan to get the game data files at least loading, and hopefully to start looking through the files for any code formatting-breakages in the upcoming time.

Einar Joha