July 30, 2016 03:00 AM All times are UTC.
Welcome to the ScummVM planet - This aggregates the personal blogs of developers, teams members and active participants from all around the ScummVM community. If you wish to subscribe to updates to the planet or individual blogs please use the links on the right hand side. To add your blog to the planet contact DJWillis.
I'm really tired as I'm writing this, but I don't want to leave it for tomorrow. I wish I could tell you of all the new features, but there aren't really any. Most of my week was spent fixing bugs which made the game crash and burn. The engine is in a playable state, taken that the player can ignore the broken display, the missing sounds and no ending. Speaking of which, I really should take a look at the numerous display functions now, fixing them would make the game look a lot more alive. Sorry for no screenshots this time, this blog post is turning out to be very short.
(PS.: Method f115_cthulhu didn't do anything, I'm just bad at interpreting errors)
It was a lovely surprise today to notice that writer Rebecca McCarthy mentioned my enhanced music for classic point and click adventure game Beneath A Steel Sky, which I spotted on the Giant Bomb forum under part 3 of her Adventure Afterlife series.
One of my all time favorite games, if cyberpunk or science fiction interest you I encourage you to play the game. It is available legally for free from SCUMVM or GoG as is James Woodcock’s ( Fan made) enhanced soundtrack, which I recommend you use. Mobile versions are also available if you want to support the dev. Rebecca McCarthy – Giant Bomb
I mentioned it in Adventure Afterlife but the Beneath a Steel Sky remix by James Woodcock is awesome https://t.co/reNMz79fXG
(I don’t have any excuse, I just forgot to post that in time.)
This week I’ve sent my Cloud storage support as pull request to the main ScummVM Github repository, and thus started fixing everything what is not fixed enough, adding new minor features, etc.
Only pasting from clipboard support was added for EditableWidgets (I’d have to fix that too, btw).
I’ve added two new test suites in the Testbed: Cloud and Webserver. I’ve also added one test for openUrl in MiscTests. Almost all my tests are interactive, meaning they require user to check whether the feature works as it should, and press the right button.
Peter Bozsó (uruk-hai), my mentor, added OS X backend for openUrl. iOS backend it not there yet.
Another small feature which lacks iOS backend is the Networking::Connection::isLimited() function, which is used in DownloadDialog to notify users to think whether they want to download game data while using limited connection. For now only Android supports this, other platforms are using default backend, which always returns that connection is not limited.
AJAX version of local webserver’s Files Manager was added this week. One can navigate through directories without page refreshing all the time. This version also contains «breadcrumbs» navigation feature, so one can get up more than one level with one click at the path.
Users can override webserver’s port through the Options dialog now. Yet, if they want to use webserver for auth, they have to use the default value.
Some refactoring/cleanup in the code and different minor fixes were made. More OSD messages added to notify user of success or failure. I’ve also updated Dropbox to use their API v2 everywhere, as v1 is deprecated now.
I’ve added detailed information about the cloud storage support and local webserver to the ScummVM wiki. These should help people understand PR’s code. Some ideas are coming out in the discussion. For example, webserver is being stopped now when users close the Options dialog to prevent it being used by someone else.
Another week has gone by. The end of the summer is inching closer and closer with every passing day. The engine hasn't grown nearly as much as last week. I managed to fix the bug with the groups, it turned out to be very simple, I was just searching for it in the wrong places. The result is that the player can progress to the next level and fight 'em wicked monsters (nice gif included), put some keys in keyholes and what not. One just has to be careful not to spin around too much or else the display code crashes in some bizarre way. The worst about it is that the call stack is messed up, it seems to be something inside the aptly named function f115_cthulhu. Code for saving and loading has found itself inside the engine as well, although trying to load a save crashes the game (couldn't muster up enough motivation to fix it yet). That's the end of the post, have nice gif: (just as always, ignore the broken cursor)
At last, the game of Shadowgate is winnable in the ScummVM platform!
There is a screenshot of the final battle with the wizard at the end (spoiler warning).
It took somewhat longer than expected, and it’s in no way as complete as I would like it to be (just look how the interface is broken), but still I’m very proud of that.
To play the game, you can clone and compile my github fork, get the game files, and unpack them using some HSV extracting tool. If anyone is interested, I have a bunch of savefiles to various rooms (more on that later).
Now, what’s next? After talking with my mentor, we have settled in the following order of prioirities to spend the rest of the time:
Fixing the GUI > Adding support for other Macventure games > Add sound > Add Apple II graphics.
I will probably be dancing around the first two, since they are not mutually exclusive and when I get frustrated with one I can work on the other.
Other than that, I try to keep my Trello updated, and the spirits up. Again, I am sorry for falling so behind on schedule, I am suffering the consequences of not doing things properly on the first try, during the June burndown inferno.
In my previous post I’ve mentioned my Container PR — and voila — it was merged! So the first thing I’ve done this week was merging it from upstream’s master into my cloud fork’s master and using the Container in the Cloud tab. I’ve also fixed a few TabWidget’s height issues in that a bit later.
Box support was added this week, so the original plan to add 4 cloud services is accomplished. Box is a bit similar to Google Drive, as it uses files ids instead of paths. The other interesting thing about it is that it has yet another approach to file uploading, so I had to tune some things one more time to support this one too.
I’m not planning to add more cloud services yet. I was unable to even find out how to work with iCloud. OwnCloud uses WebDAV instead of OAuth2 + REST API and they are not going to implement one. I’m not sure how long will it take to add WebDAV support, so I’d be working on other things for now.
A few upgrades were made in the DownloadDialog and local webserver’s Files Manager. The first one now shows progress a bit more precisely because it’s calculated based on downloaded size, not the number of files downloaded. It also shows the downloaded size, total size and current speed there.
Files Manager now supports directories uploading (works in Chrome only, as that’s the only browser where this feature is implemented). I’ve also added code which should correctly determine server’s IP on Linux. Some minor improvements like file type icons were made:
Finally, I started working on openUrl and clipboard support. Windows, Linux and Android already support opening URL in the browser, OS X and iOS backends are on the way. I also have some Symbian code, but it could take some time to implement it properly.
Clipboard is already supported in SDL2, and I just started working on adding it. Right now it’s only Ctrl+V support for EditableWidget. We’re also thinking on adding selecting feature there, so users could also use Ctrl+C. I’m not sure how that should work on platforms like Android, where we usually don’t have keyboards attached. I mean, EditableWidgets are not Android EditText fields, so they don’t show a menu on long tap, which means we either implement it or make users suffer.
These two features are what I’m going to work on. Then I also should add some tests into testbed engine, and do some documenting/refactoring where needed.
Hi all. Been a while since my last posting; and a hectic last couple of weeks. After flying down to Florida for a 4th July long weekend getaway, I was barely back before I had to get ready for a work trip to the west coast. Then I get back to two days of company photo-shoots, which kind of disrupted getting back to normal work; but no sooner than they were done, I come down with a cold and had to stay home for several days. And was too sick to even really use my computer until now. :(
Nevertheless, despite all of that, work has been progressing on Starship Titanic since my last posting, and I've made a lot of progress. Firstly, there's the PET User Interface. This was one of the major areas that still had to be investigated last time. Since then, I've spent a lot of time figuring out how everything works, and re-implementing it all in my ScummVM engine. Behold the fruits of my labor:
Code for all the various areas has been pretty much all implemented. You can enter text in the conversation tab, and click stuff in all the others. There's just a few minor visual and functionality glitches here and there, such as the dials in the above image. Some of the tabs, like the Remote and Rooms tabs, are mostly untested at the moment.. it will be easier to test when I have more of the game logic implemented, and can properly test them with live data. Saving and Loading is also waiting on me to finish the saving and loading code.
As before, I was aided somewhat in implementing the PET by how clean the class hierarchy was designed, and the fact there were various internal error messages scattered about the code to give an indication of the classes' original names and purposes. For example, the code has a single common class CPetGlyph for the square glyphs used in all the different PET tabs, and CPetGlyphs for the collection of glyphs, with all the logic for scrolling and rendering. Individual PET areas simply derived from that, and instantiated whatever glyphs were needed, be they action icons like for Save, Load, and Quit, or inventory items that can be selected.
Once the PET was pretty much done, I started looking into the conversation handling and text parsing. To begin with, I worked one of the easier, self contained areas of vocabulary loading. All the vocab data for Starship Titanic is held in a resource inside the game executable called STVOCAB.TXT. It holds the data for an impressive 4700 words! A lot of these come down to synonyms for common words, and in fact even includes foreign language words, like "ein" as a synonym for "a". Each word entry in the file also contains data for what kind of word it is (such as action, adjective, etc.), as well extra information that is used by the parser to uniquely identify the words. The vocabulary loader builds up the data for each word in turn, building a master list of overall words support by the game, and a linked list of synonyms for each word.
Once I did that, I started looking into the input processing code that gets called when a line of text is entered in the PET. First of all, the game calls some pre-parse methods. These take care of a bunch of standard processing of the line, including:
lowercasing everything and removing extra spaces between words
Conversion of numbers from textual formats into decimal. That was surprising.. the game has special code in place so you can enter numbers like '42', 'forty two', or even 'LXXIII'. That's right.. the parser is so sophisticated, it even handles roman numerals. :)
Expanding common contractions like "it's" to "it is".
Once preprocessing is done, it then breaks down the entered sentence into a series of words. Each word is checked against the word synonym lists to identify the known word for each entered word. Here again, the parser has extra complexities that surprised me. It can not only find word matches based on exact word matches, it has two fairly complicated routines that can identify various forms of pluralization, as well as common word prefixes like 'super', 'anti', 'counter', etc. and find matches on the word without the prefix. At the end of this process, the entire input has been broken done into a linked chain of recognized words, and the real handling of figuring out the player's input can be done using custom logic for each NPC script.
At this point, whilst I had made some inroads on NPC script handling, I somewhat started drifting on what area I worked on. Strangerke had been looking at some of the core game scripts to add me in writing game logic, so to make things simpler in the long-run I went back to the main CGameObject base class, and spent some time figuring out all the remaining unknown methods. Quite a few of the methods were basically stubs calling PET Control methods, so my prior work on the PET was a great help.
Next, there was a bunch of CGameObject methods calling movie code, so I decided it was finally time to figure out what it was doing. I was able to properly implement the game's OSMovie class which handles movies, and it's AVISurface which handles the low level AVI files. It was actually interesting in that some videos have a second video track - I haven't 100% disassembled the movie drawing code, but my impression is that pixels in one are transparent, and in the other are not. This required me to add an extension to our AVIDecoder to allow a callback method for selecting which streams the AVIDecoder would use. That way, I could set up two decoders in the AVISurface class, one with the audio and first video track, and the second with the second video track, if present. This neatly avoids the limitations of one video track per decoder. The replacement movie code is all implemented now, but apart from cursor loading working (the cursors are stored frame by frame as a video), movie playback is still crashing, and will have to be debugged further. But at least I know what the bulk of the movie methods are now.
Finally, I moved onto the Star Control class. This is what implements the game's starmap control.. with PET mostly implemented, NPC scripts partially implemented, and movie handling more or less done, only it and sound are left unlooked at. And as I've mentioned previously, sound handling has a lot of spatial processing for sounds that I may simply not implement - the AVIDecoder already handles video sound, and I'm hoping to hook up the other sound methods to simply use standard ScummVM sound decoders. So that makes the star control the only remaining large area to look into.
Oh boy, and what a large area it is. Even basic identification of classes was already bumping up to nearly 30 classes all specific to just the star control. I felt greater and greater dismay the further I looked into it. Honestly, it was like Hopkins FBI all over again, where they included a full Wolfeinstein 3D style minigame in the PC release. In that case we were lucky, and could simply ignore it. Not so much in this case - all the classes will have to be implemented.
As I've looked into it further, and worked on classes that don't depend on others (so are self contained, and in theory easier to figure out), some of them have started to make sense. There's matrix and vector classes.. somewhat surprisingly, two versions of each, one for floating point numbers and one for doubles. I can only assume back in the day there was space vs speed considerations for having both types; I've not yet reversed all the methods, so I don't know if they can be merged in the future. I've also identified two "star points" classes that use large lists of spatial data that was hard-coded in the executable. Hopefully, the other remaining classes won't be too hard to figure out likewise.
So, all in all, things are going good. I'm starting to feel better, and I'm making inroads on the last major area of the game. Once I get that out of the way, it'll be a matter of finishing off the NPC scripts, implementing miscellaneous methods here and there such as sound handling, and then implement the game logic. Which, with all the core engine implemented, will hopefully be a straightforward, if slow process.
The engine is coming along well. Great many lines of code and even greater many bugs have been incorporated into it this week. It seems that for every bug I fix, that makes the engine crash and burn, there are three more waiting right around the corner. Right now the most inconvenient one is that group management has not yet been tested as there have been zero enemies on the 0th level and as I've spent most of my time fixing bugs there (for example making the damned door open when the player steps on the pressure plate in front of it). So when the player takes the stairs, the game goes down with a segfault. Items can now be put into the inventory, they can be placed and be thrown around. Interaction with the dungeon is more or less in place, the player can press buttons, step on plates and uhhh that's all there is in the hall of champion people. The champions can now attack and take damage (don't walk into walls). The former has not much use, since we can't even get near enemies yet. I planned on having some screenshots of combat, but since I can't get me some real enemies right now, you'll have to watch me fight this wicked door instead.
This last week has been, for the most part, incredibly frustrating. The inventory system had so many little bugs in it that it seemed that when I fixed something (often after most of the day looking), something else broke. However, somehow I managed to get it working, and thus, with the skeleton key in hand, I can go on to the fun part of the project: QA! In all seriousness, in the upcoming week I will be focusing on just following a walkthrough of the game to detect and solve the little bugs in the way of winnability. I had a milestone in my planning to have Shadowgate winnable for today, with which I meant a much more polished state that it currently is in. However, several factors and my frustration (no-one but me to blame here) have made it impossible to acomplish.
Well, actually, I wouldn’t know currently whether Shadowgate is winnable or not, because there is a little bug that prevents me from lighting more torches, and that makes it near-impossible to advance more than a few rooms. However, I am really please to see that at least there is nothing major preventing me from playing the game, and that the systems I put in place (read: “copied”) are more or less working.
So, without further ado, here are some screenshots of the first rooms of the game:
Again, I apologize for the short clips, but it is a combination of my switching to Arch Linux (and the limitations of the software I use to screencast) and my general slowness while playing.
I am hopeful that, by the end, I will have a product that I can be proud of, and hopefully somebody can enjoy (I for one am having a blast playing through this game).
This week started with the DownloadDialog, which allows users to download directories from their cloud storage onto their device. Navigating through the remote directories is a bit slower than browsing local ones, but it works fine. Download is done in the background. On the completion, OSD message is shown. If DownloadDialog was not closed, ScummVM automatically detects the game in the directory (the way it works in «Add Game») and suggests options. «Add Game» also checks whether you’re trying to specify the currently downloading directory — and notifies that this is forbidden. I’ve also recorded a video showing how storage connecting and game downloading features work:
(Youtube video in iframe here)
Then I started working on the next feature on the plan — Wi-Fi Sharing. Now there is a special «Run Server» button in the Cloud tab, which one can use to start local webserver. It also shows its IP there (works on Windows only yet):
I’ve added «/files» path to the webserver, so that’s where one can browse directories on the device. Clicking on a file causes its download, obviously. There are also two buttons: «Create directory» and «Upload files». One can’t upload directories yet, but multiple files uploading works fine.
I’ve tried downloading a 349 MB file from that webserver and it took me 16 seconds. That’s about 22 megabytes per second! Unfortunately, I can’t say the same about uploading. It took me 20 seconds to upload a 9,5 MB file and 11:15 to upload that 349 MB file. That’s about a 0.5 megabyte per second. Handling multipart/form-data POST is not an easy thing, and it doesn’t work fast in my webserver implementation yet.
What’s next? My Container PR is not merged yet and this week features might need some polishing after review. The next thing in the plan is to implement the fourth cloud support.
As I mentioned in my last blogpost, I was planing on fixing stuff I blew at the beginning, that has been done, thus I can add code much more rapidly now and with less mistakes. If I put my back into it, the bulk of the code should be done by next weekend (no promises). Of course, that would not be the end the work. Code has to be cleaned up, global arrays moved, some refactoring is due. Some display functions are missing entirely or are broken, and I've been putting off fixing them for a while now (color palettes for example), I plan on dealing with them when the rest of the code is in place. There is also other stuff, like making the code compile under something than msvc14, testing if it even works on other platforms than windows, although chances are, I won't be the one fixing those issues.
What I've got for you this week is moving them items:
If you just ignore for a second that the cursor display is completely messed up and that the GUI is kind of broken, the pictures might actually look appealing.
Next up should come stuff like dungeon interaction, combat, inventory etc. All the good stuff.
This week has been rather weak on progress, due to various factors but one of the biggest was that I got stuck trying to make the drag work. I’m still stuck on that, but trying to fix it I have made several small pieces of progress, and I have something to show. The two main pieces of progress are that I revamped the click detection system, and now the double click is working, and that the text output system (or a prototype, lacking scroll). Here is a brief walftough of the latest state of the game:
I’m sorry that I don’t have much more to show, but I feel closer to something playable.
As I mentioned in the previous post, I had a few things to do this week: our university team was playing AltayCTF (we won the first place) and I had to move out of the dormitory. To compensate these days off, I’m working this weekend.
As planned, I’ve implemented clipping in all the other drawsteps and used these in all widgets. Now we can put any widget in the container and it would be clipped as it should be. More screenshots could be found on the special page.
Then I got all container-related commits in a new branch (because my separate container branch was based on cloud branch, as I had to test my container on Cloud tab) and issued a pull request.
I guess I’d spend some time polishing that when I’d get some feedback, but until then I’ve decided to test my cloud feature on Unix. All this time I worked on Windows and was using MinGW to check it could be built in Unix-like environment, but never launched that on actual Unix. I installed Kubuntu in VirtualBox and cloned my repo.
The first thing I found out is that our configure stops if there is no curl_config. I guess that’s not OK, because if there is no curl_config, we probably should build ScummVM without curl support (i.e. without clouds). Yet it works fine without SDL_Net installed, so my first built ScummVM was supporting clouds, but not local webserver — that’s how I checked that storage connection wizard works fine.
Then I installed SDL_Net and rebuilt ScummVM to check that the local webserver works fine too. It is. The saves sync wasn’t, though. I had to fix a few minor bugs, but that was easy. Now saves sync is OK too. I was lazy to edit .gitconfig or to setup a shared folder, so I just used ScummVM’s sync to upload necessary source files into my Dropbox :D
When I’d be done with the container, I’d start working on cloud files management — some GUI dialogs which allow users to upload and download game data.
My exams were over, I now have to turn my attention back to Director engine. I continued to work 5 days ago. And next things have emerged:
Starting from Director 4, RIFX containers can have little-endian byte order, specifically for this, regular ReadStream was amended to ReadStreamEndian and now engine can work with both orders. In so doing, byte order is determined by first tag (“RIFX” or “XFIR”)
In the majority of the movies, casts not stored directly in the movie. There is a special file, with a special name (surprising!) that stores, common to all movies in folder, sounds, images, texts. For this situation, renew shared casts immediately after jumping to new folder was written. Shared may be some regular buttons for game.
For example: (Spaceship Warlock in our engine)
But determine shared cast movie name still a problem.
Significant progress has been made by sev : storing local/global variables, Lingo macros, built-in-functions and more… On my part, were introduced execution go to loop, go to next/previous commands.
Reading text resource realized a long time ago, and it time to deal with rendering issues. Director font map has been reviewed by sev. And it was decided to use classic mac fonts data file for drawing our text. Future target: rendering with box shadow, borders (if needed)
These were the words that made the engine start to come to life, sice it meant that you can now select commands, objects, apply commands to those objects, the script engine is capable of running the door’s script and the text can be decoded. The engine is far from complete, and there is still a long long way to go, but I’m grateful that I can continue (as of yesterday, without university work) working on this piece of sorftware. It’s great to see such a big project (for me, at least) come to be.
Here are some screenshots of the progress so far, in more or less chronological order:
Here we can see the full text decoding, with the huffman tables for articles and prepositions fully loaded.
This is an image of the inventory interaction, and proof that we can use the inventory are the words “the door does not catch on fire”
Here is the latest advancement, the dragging feature:
As I said, it’s far from complete and it needs polish (that mouse rect is off), but it’s starting to look more alive. Now that I don’t have uni work, I can dedicate fully to this.
As it happens, I needs to complete some work related to my student status. It’s about my exams. In this regard, in the coming week my time should be given to questions about tropical geometry and information models/processes.
At the end of week, I will continue to work on Director engine.
And once again I’m writing about my GSOC progress.
Loading transition info and implementation of some movings (8/52).
Imitation 2 track sound system (such as in Director).
Rendering trail sprites (it works like background images)
Parsing new kind of scripts – movie scripts.
Speaking of scripts, there is a work on the Lingo compiler by sev. There is, at present execution some media interface commands like play part of sound files and the processing of alias map. Also put/set commands have been added.
Were reviewed, Director ‘go to movie (label)‘ commands. In many games this is main command, with this you can simulate walking across levels. But this transition using special name of movie, and because of that movie loading was redesigned.
I know I promised to show The Journeyman Project movie files. But right palette still got trouble.
Specifically for this post, I’ve copied in my local code, palette, which contuinity uses as fallback. And some of JMP movies seems more or less pretty.
A week went by, engine changes, but slowly. Now is the moment when differences in Director versions are important.
Under the supervision of sev, I started to learn life cycle of the playback/draw system, it’s important because it can tell about when causes local events, such as frameEnter, frameExit, idle. In other words, we want to achieve event order, same as in Director. For me personally, it was hard to figure out what order is correct, sev advised me to check it right in Director. Because our target game is Journeyman Project, I looked in 4.0 version. By writing a simple script, I have found right positions in my code for calling this events.
It is worth noting, that in other versions the order differs, part of the problem is new events (D6: stepFrame, prepareFrame, beginSprite …).
Maybe you have already guessed that, this events are necessary for our feature Lingo interpreter. In addition to the system events, I’ve also added mouse events, this event are sent to clicked sprite on top layer.
Simple sound wrapper had been written, in JMP we’ll see .wav and .aiff formats. ScummVM audio decoders deal with this.
Decoder for 1bpp pictures was also added. This pictures are sometimes used instead text.
There is now some issues with 256 color palette loading. I hope problems will be solved, and in the next report I can show movies from The Journeyman Project.
While traveling through space in his spaceship, Gnap ran out of gas and crashed
in the middle of a redneck farm. He's now lost on planet Earth and needs your help to fix
his U.F.O. so he can continue his journey!
The ScummVM Team is proud to announce that U.F.O.s aka GNAP: Der Schurke aus dem All is
now playable in ScummVM using the latest daily builds,
and is ready for testing.
It has been a couple of months since ScummVM 1.8.0, which means it’s time for
a new point release! ScummVM 1.8.1 is now available with fixes for important
bugs and support for even more platforms.
One of the most important "features" of this release is a major upgrade
to the Android port. This upgrade also adds support for the OUYA console.
We are currently working on bringing this new release straight to Google Play,
but for the impatient among you, feel free to go ahead and
install the APKs manually. The Android
port now comes in two flavours, our "classic" OpenGL-based one, and a new
variant based on SDL. The SDL port has better compatibility with some Android devices
and also works better with some engines. Please give it a try and tell us on
our forums or via
the bug tracker about your experience.
We will also be adding Nintendo 3DS support! As of release time, the new binaries
have not yet been built by our new porter, but they should be available soon.
Keep your eyes peeled!
64-bit Mac binaries now include experimental automatic update checking using
Sparkle. Auto-updating is selected as an
opt-in during your first start up, and by default checks weekly for new releases.
When version 1.9.0 is released, users of 1.8.1 will be presented with
a nice dialog for updating. If you'd like to see a similar feature for Windows or
other platforms, let us know! All the details on how the update process works can be
No ScummVM release would be complete without game engine
updates! ScummVM 1.8.1 includes fixes for Drascula, Legend of Kyrandia,
Labyrinth of Time, localized versions of I Have No Mouth,
Broken Sword 2.5 and improvements to the Windows, OS X and GCW0 ports.
Although I have never officially announced my work for classic point and click adventure game The Gene Machine, I have already finished the soundtrack… Just one problem, before I release it in full, I need permission. I have always sought permission to release my enhanced soundtracks, however tracking down those who have the rights to allow me to do just that has proven… well… problematic!
To whet your whistle however, I have decided to release a single track as a preview in the hope that one day, the powers that be will contact either myself or the ScummVM team allowing this to happen.
Until then, enjoy this little taster as we all keep our fingers crossed.
Since the 1.8.0 release we've been very busy with fixing small and big bugs in the newly supported engines,
and now we are almost ready to present you the result in a form of the ScummVM 1.8.1.
Please, help us to test a few games, especially those which were not touched for a long time,
or those which have significant changes in their engine. We prepared a short list on
Also from now on we encourage you to test any game which we support and report any bugs or
your success on the forum so we can keep track of current state of affairs in the ScummVM Land.
For testing the pre-release you need to download a daily build
of ScummVM. If you spot some glitches or bugs, please report them on our
bug tracker. If everything went smoothly,
please report your success on the forums,
and we will instantly reflect it on the wiki
(yes, you can be famous for your testing efforts!) You can find a guide on how to test a new release
A few games are still missing screenshots. Please
help up complete our gallery.
As you may already be aware, this year the ScummVM project is participating to the Google Summer of Code. One of the rules for students who want to participate with us is that they need to submit a simple patch against the ScummVM source code before they are accepted. Usually we direct prospective students to our bug tracker for ideas on what they could implement. But now most of the bugs that are still open are not trivial to fix. So I was looking at the source code hunting for simple things to do when I found a TODO comment I left two years ago when implementing the TaskbarManager API on OS X.
What is the TaskbarManager API?
The TaskbarManager API allows interacting with the ScummVM application icon in the taskbar (or in the case of OS X in the dock). We have implementations of this API for several systems, but the only one that is complete is the implementation for Windows. In details the API allows to:
Display an overlay icon when playing a game. If you have in your extra path png files named after the game IDs, when starting a game the corresponding png image is overlaid on the ScummVM icon in the dock. You can for example get icons from http://www.megamonkey.org/icons/ and below is example of this feature in action.
Display progress. This is for example used in the mass add feature to indicate the number of directories scanned in respect with the total number of directories to scan.
Display a count. This is also used in the mass add feature to indicate how many games are being added.
Notify of an error.
Provide a list of recently played games.
The last two were not implemented on OS X and the TODO comment was related to the last point. The idea was that we could provide a list of recently played games in the ScummVM dock menu and thus provide a shortcut to start a game quickly. I decided to take another look at this feature and wrote some bits of code to check that the idea I had hinted at in the TODO would indeed work. I then waited a few days in case a student wanted to implement this as part of his application to the GSoC. But today I finished implementing this feature, cleaned the code and pushed this to the ScummVM repository.
One aspect to consider here is that we want to customise the menu on the ScummVM icon in the dock when ScummVM is not running. That way we can propose a list of recent items in the menu and start ScummVM directly with a game. On OS X we can provide this feature with a plug-in that implements the NSDockTilePlugIn protocol. If an application bundle contains such a plug-in, the OS loads that plug-in when the application is added to the Dock. So there are actually two separate things to implement:
Obviously we need to implement the plug-in.
But we also need to implement code in ScummVM to update the list of recent games when starting a game.
Saving the list of recent games
The TaskbarManager is part of the ScummVM application and when starting a new game the addRecent method is called. So what I did here was simply to save the list or recent games in a place where the aforementioned plug-in can find it. I decided to use the NSUserDefaults class to do this, which means the list is saved in the user preferences (to be precise in the ~/Library/Preferences/org.scummvm.scummvm.plist file).
(if you don't see the source code below visit the blog as it may not be visible in RSS feeds)
That code is a bit too simple though. There are two main issues with it: the list can grow indefinitely and the same game can appear multiple times in the list. So let's improve the code that updates the array of games.
And that's it. We have this part fully implemented. After playing a few games the ~/Library/Preferences/org.scummvm.scummvm.plist file should look like this:
Implementing the NSDockTilePlugIn
If you took a look at the NSDockTilePlugIn protocol documentation you will have seen that it requires implementing a setDockTile: method, and optionally we can implement a dockMenu method. We actually have nothing to do in the first one, so let's skip it and look directly at the second method.
Here we can note that I am using CFPreferences to read the list of recent games and not NSUserDefaults. Why is that? Do I need to remind you that this code is in a plug-in and not in ScummVM? That means we need to access the preferences of another application. Admittedly we could have used NSUsersDefault addSuiteNamed: to achieve this, but remember, we are implementing a plug-in and not an application. The plug-in is loaded by the SystemUIServer and using NSUserDefaults addSuiteNamed: would have changed the global preferences domain list for the SystemUIServer and not only for the plug-in.
The second point we can note is that the code above is using something called StartGameMenuItem. As you have probably guessed this is a custom class that derives from NSMenuItem. Indeed for each menu item I needed to store somewhere the game ID so that when this menu item is activated it can start the corresponding game. So I decided to inherit from the NSMenuItem class and store the game ID in the derived class. And while I was at it I also added the method to start a new game in that derived class. So here is what this class looks like:
Now if you add ScummVM to the dock, and after playing at least one game, you should see the list of games you played recently in the the dock menu like in the picture below. This provides a quick way to start one of those games.
And here is what it looks like in action:
This is in my opinion the most useful of the features provided by the TaskbarManager API, so I am happy to see it finally implemented (I would have done it sooner if I had not forgotten about it :P).
Edit: Our buildbot uses an older SDK that does not support the NSDockTilePlugIn protocol. So nightly builds from our web site will not contain this new feature. You will need to compile your own version or wait for ScummVM 1.9.0.
On Friday Google announced the accepted projects for this year's Summer of Code. We are pleased to say that ScummVM will be mentoring four lucky students who will have to spend their summer in a dark room in front of their screen. We expect this will be an interesting Journey, passing through shadowy gates to visit scary dungeons under dark clouds. All while the mentors will be hunting three-headed monkeys on a tropical island, enjoying the sun, the beach and the grog.
Borja Lorente Escobar (a.k.a. blorente) will be working on porting the MacVenture engine to ScummVM.
Bendegúz Nagy (a.k.a. WinterGrascph) will work on adding support for Dungeon Master
Dmitriy Iskrich (a.k.a. Iskrich) will be working on a Macromedia Director engine, with focus on The Journeyman Project
Ткачёв Александр (a.k.a. Tkachov) will be adding cloud storage integration to ScummVM to allow sharing saves and game data between devices.
Welcome to our students for what we hope will be a productive and interesting summer! You can follow their progress throughout the summer on the ScummVM Blogs.
What began as a casual lunch-time activity (spread across many, many lunches), my work on Douglas Adam's Starship Titanic is finally starting to see significant results. See below for an example of the current progress from the start of the game: https://www.youtube.com/watch?v=8ypLR4fS6vE
You can't get as far as the ship crashing into your house yet, but at least you can fiddle around with the computer and, more importantly, use the television, and see Douglas Adm's visage scolding you to get on with the game. :)
I was originally attracted to working on the game more for technical reasons then the actual gameplay for several reasons. Firstly, because it was a Windows game.. my previous disassembly work has all been on DOS games, so I thought it would make a nice change of pace. Secondly, the original executable relies on compatibility tweaks to run on modern Windows systems and, according to the GOG forums, multiple people have had trouble getting it to run at all. And thirdly, the ease of disassembly.
The game has, in my opinion, the cleanest and most well thought class structures of any game I've worked on. Part of this clean hierarchy involved the bulk of classes in the game deriving from a common "CSaveableObject" base class that defines, amongst other things, the name of the class. The entire game state is laid out as a tree sturcture, with CRoomItem objects for rooms, CNodeItem objects for positions within a room, CViewItem for the different directional views within a node, and game objects under each view. Saving and loading games, including loading the initial game state for new games, is then a simple matter of dumping the hierarchy to and from disk.
Because of this, it's made it somewhat easier to reverse engineer how the classes are implemented. Since the game loading code needs to be able to locate and create classes by their textual name, it meant that I was able to properly identify and name all the classes the same way they were in the original source code (which I don't have access to). Since the original uses C++ classes and inheritance, it's meant that when I've identified the meaning of a virtual method, I could apply the same name to the same method in all the other objects. So, for exmaple, when I identified the methods for saving and loading an item's fields, I was able to focus on those same methods in all the other classes to handle loading the entire game state.
So as you can see from the above video, progress on the engine is going well. I have all the core logic in place for loading the initial game state, displaying views, and moving between them. I've also been able to graft some of the original's movie class, that handles playing AVI videos for all the game's animations, to use the existing ScummVM AviDecoder. Although there's still parts of CMovie that I don't understand. And there also isn't any background sound yet. Apart from that, there's two main areas left to be handled: firstly, all the hardcoded game logic. If there's one thing that I find a pity, it's that rather than using some kind of scripting system, they chose to implement all the game logic in code. So all the various interactable objects in the game have their own code that will need to be slowly implemented.
The other main area remaining to be figured out is the PET control that provides the game's user interface. Particularly the conversation system, where you can converse with the characters within the game. I've already made some minor in-roads into implementing display of the PET, and various error messages in the original executable have given me some ideas of various classes in the conversation system. But it will still take a while to fully implement the game. Plus of course, dispute recently working on it quite a bit in my off hours, work on this game has primarily been a lunch-time diversion, so it's somewhat limited by my work's totally unreasonable policy that lunch should be limited to only a single hour each day :)