July 01, 2016 04: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.
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.
First of all, I finally passed my exams! I’ve got a few things to do, but in July I’d be completely free to work on my project. That’s why I wasn’t too active this week and wouldn’t be on the next one.
So, this week I was working on non-cloud-related thingie: a new GUI widget, which would contain other widgets of unlimited total height — the Container. Well, it’s actually a ScrollContainerWidget, and the main thing it has is a scrollbar. As I said in the previous post, one of my dialogs — the storage wizard — is too lengthy to be displayed in that area where ScummVM shows its dialogs. We decided that I should implement the Container, so we can put dialog contents in it, and in these cases when there is no room to display all of them, the scrollbar would automatically appear and no overlap will happen.
The first thing I changed was label — it already has a clipping rectangle, so I only had to pass the right values. Then the fun (to be read as difficult) part started. Widgets doesn’t have any clipping rectangle, which means you can’t just make the button draw only part of it. And, well, each widget has its own method, so it means I’ve got to change all of these in order to make them support clipping.
I started with buttons and PopUpWidget, because those are used in the Cloud tab of the Options dialog. Their drawWidget() method calls the corresponding drawButton()/drawPopUpWidget() method of ThemeEngine. ThemeEngine uses queueDD() and queueDDText(). Some DrawData objects are created in there, then their draw steps are called. If I recall correctly, draw steps are methods of VectorRenderer, which has VectorRendererSpec backends with implementations of these. So, I’ve got to pass that clipping area information from Widget though ThemeEngine and DrawData objects right to VectorRendererSpec and use it there.
Each of those draw step implementations has some additional functions in VectorRendererSpec. And these functions have some complicated logic and lots of macros usage. And none of these happen to think that clipping would ever be needed.
So, buttons are using drawRoundedSquare() draw step method. To minimize the possibitility of breaking something, I decided to leave these methods and add new ones — drawRoundedSquareClip() in this case. It checks that clipping is actually needed (i.e. button area is not completely in the clipping area), and if not, uses the original one. If clipping is needed, then other Clip-versions are used. So, drawRoundedSquareAlgClip(), drawBorderRoundedSquareAlgClip(), drawInteriorRoundedSquareAlgClip(), gradientFillClip(), blendFillClip(), colorFillClip() and a lot of macros with names like BE_DRAWCIRCLE_XCOLOR_BOTTOM_CLIP() arrived.
All this — for rounded squares. And there are also triangles, circles and other draw steps, which I didn’t touch yet. But still, Container already works with buttons, PopUpWidget and labels, and I guess in some cases it would be enough to add new draw<WidgetName>() and use all these methods, which already do clipping, so it should be getting easier as I go further. The plan is to make all other widgets support clipping, so Container could be used with any of them. Apart from that — it seems to work fine.
Indeed, their greatest achievement so far is that angry looking lizard person dude in the top-left corner. Great many lines of code had to be written (copied really) to make this scene. The keen-eyed between you might notice the obvious, that there are a couple of things missing. Slot icons are not drawn yet and all of the text (that is not part of a picture) is missing as well. Reason is, that the function which draws letters on the screen is lots of assembly and well who wants to do that. We figured that it probably just treats the font table as a 2D array, plus some word wrap etc. So champion selection is still not done yet, duct tape code gets us here into the inventory screen right now, no way to leave it yet. Next up should be swapping the dummy code for the real stuff, the try some text display and that might actually make my second milestone complete :) PS.: Technically speaking, I should have made this blog post yesterday, but I had not much to show for, good thing I gave meself 90 days tops:) PS.: Color palettes will probably be fixed somewhere near the end, so we'll have to tolerate it until then.
As the title says, I feel that the engine is starting to take shape at an exponential rate. As I get intimately familiar with the engine and it’s inner workings, the cycle of adding functionality becomes shorter and shorter. The experience I have aquired with GDB helps a lot, too.
For now, the big components I feel I have ready are:
The main class structure of the engine: I think I have settled on how each thing can communicate with each other. In the end, I think it will result in somewhat of an MVC pattern, in which the World and *Asset (TextAsset, etc) are the model, the MacVentureEngine and ScriptEngine classes are the controller, and the Gui class is the view.
The main loop of the engine: The engine uses certain object queues, and those and the logic of the game flow is pretty much implemented. There are particular functions yet to be completed, but I am confident that I can implement them in a fairly short amount of time (I would have done it today, but Microsoft auto-updated my scrap computer to Windows 8.1, which took a big bite off my day).
The asset loading: All assets use the same container format, whose decoding is complete and tested. In addition, there are specialized decoders for about half the assets (Text, Scripts, and SaveGames). The remaining ones are Graphics and Sound. I estimate that the former will take me a couple of days, while the latter I will leave for after the midterm.
Save game loading: The savegames use the same container format as every other asset, so loading (and saving, though that’s not yet implemented) should be a non-issue.
Window system: The GUI can now read data of all the main windows of the engine, as well as update that data, register callbacks and create new inventory windows (these are dynamic).
The script engine: The script engine structure is pretty much finished, and most of the opcodes are implemented. There are some left, because either they had to do with yet unimplemented things (graphics, sound, or particular accessor functions) or because they required some non-trivial functionality, which I’m adding right now.
Now, there are still some things to be done:
The graphics decoding, while not hard (I practiced with the text decoding) will have to be done, and it will be tedious.
The gui event registration, to handle the clicks and object selection on the windows. This will be done after the graphics decoding.
The .bmp borders, which I’ll have to finish.
That is most of my progress so far. I feel like, if I have a working game by June 26th (a strong posibility), I will be ahead of schedule by about a week. That’s amazing, and I’ll give it my best so that it happens.
As always, my schedule is available at Trello, and you can follow the progress in the GitHub fork (it’s the macventure branch, mind you). Also, I sometimes stream my programming on Twitch.tv, feel free to come say hi.
This week I have upgraded the StorageWizardDialog. Instead of one big text field for code, we decided to put eight small text fields. The scummvm.org page shows the code you should enter, and each code group correctness is checked separately.
ScummVM also automatically checks that the whole code is correct, too. When you enter a valid code, «Connect» button becomes active and you can get your cloud storage working.
However, we don’t think that 40 symbols long code is an easy thing to enter. We’re working on different ways to simplify that task, and one of them — probably the ultimate one — is not to enter that code at all! To achieve that, we’re adding a local webserver into ScummVM. For now, it looks like this:
When you open the StorageWizardDialog in the ScummVM built with SDL_Net (i.e. with local webserver support), there are no fields. Only a short URL for you to visit.
When you do, you’re redirected to service page, where you can allow ScummVM to use that service’s API. When you press the «Allow» button, you’re automatically redirected to ScummVM’s local webserver’s page — and ScummVM automatically gets the code!
I’ve also done a few updates of cloud sync procedure, so now it automatically started when you connect to a storage, or when you save the game or when the autosave happen. The last time I said that if you decide to cancel the sync, the currently downloading file would be left damaged. Well, not anymore — such files are automatically removed.
Finally, we came up with the plan! :D
First, some of my GUI dialogs require more space than ScummVM can provide. So, we decided that I should implement a «container box» widget — an area with scrollbars, which would be providing more virtual space than we really have.
After I do that, I’d start working on cloud files management: users would be able to upload and download their game data right through ScummVM interface.
Then we’re going to add a «Wi-Fi sharing» feature. It basically means that local webserver would be also used to access files on the device through a browser. No more USB cables! You can copy files from your phone by clicking a link in your browser or upload files onto your phone with that.
Then comes the next cloud storage support — Box. I know nothing about it yet, but hopefully it should be similar to those three I already added.
And in the end, I’d work on those things that would make it easier to enter the code if your ScummVM doesn’t have the local webserver feature. Those are browser opening and clipboard support. So, ScummVM would be able to automatically open a browser for you to allow it to use storage’s API and you’d be able to copy the code and paste it in the ScummVM’s text fields. These are interesting features, but as far as I know, those are highly not portable. For example, there is ShellExecute on Windows and special Intent on Android, but no such thing in Unix. And not all platforms even have the clipboard. From the other hand, there is SDL_GetClipboardText()... in SDL2.
Anyway, I’ve got one (and probably the most difficult) exam to pass the next week. Yeah, an exam and the midterm at the same week. I hope I’ll be able to do at least that «container box» :D
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.
I managed to display a static image, that's gotta be progress, right? So mouse input is in place (sort of), hitboxes on the screen are getting registered correctly, keyboard input is hacked in for testing and I have this cool picture of arrows in the right corner with miss-matched color palettes and an out of place green cursor, nice! Don't worry, more is coming (in like 3-90 days). And by more I mean champion selection and inventory stuffz, oh boy won't that be fun! Well it would be, if not for the monstrously long functions. The worst about them is that they are heavy on compiler variable sharing because they were meant to produce the exact same executable as the original source code would (sound very much insane, right?) when compiled with the same compiler. And that's it for this blog post.
As a finishing side note, there shouldn't be any hiccups since I'm finished with all the exams, thus my studies won't be weighting me down and I don't have much to do right now aside from coding up this super cool game.
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.
So, this week I worked on the GUI mostly. That Cloud Options tab is almost fully functional — we want to modify Connection Wizard a little bit, so it helps users enter the code (which is quite long, about 40 characters). Apart from that everything in the tab works as it should, so you can easily switch between your connected storages, see how much place your saves occupied on your cloud drive and when the last successful saves sync was. The Connection Wizard works too, yet, as I mentioned, it won’t notify you of typos. We’re working on corresponding scummvm.org URLs, and these work quite fine.
I’ve also added Google Drive support this week. As Google Drive uses file ids instead of paths, that wasn’t a very pleasant adventure. I mean, imagine you want to download a file knowing a path to it. However, you can’t just ask to find that file because there are no paths in Google Drive. So, you have to divide the path by separators, start from the Google Drive root folder and implement path traversal by listing the directory, finding a corresponding subdirectory and repeating these steps. And, as there are no paths in Google Drive, there could be files with the same name! So, there could be two ScummVM folders or three Saves folders or five soltys.000 files. Well, I just use the first one’s id, so if you’d try to mess up with the Google Drive’s ScummVM folder — you’d succeed. Also, as we wanted to give more freedom to the users, we had to ask for the whole Google Drive access, because application data folders are completely hidden from users. ScummVM only creates its own folder in the Google Drive root directory, so fear not!
Finally, I worked on the progress dialog for the save/load manager. During the saves sync some slots could be unavailable because they are being downloaded. You’d see the following dialog in this case:
Most engines use the common pattern for their save files, so I called these engines «simple». If it’s «simple», you can press that «Run in background» button and you’d see all the slots. Some of them would be «locked» and would lack the thumbnail, but all the others would be easily available to save or load. Unfortunately, there are also «complex» engines. I was unable to implement that «locked» slots feature for these because of their complex nature, so «Run in background» would be unavailable. You would have to wait until all saves are downloaded, and only then save/load feature would be available. You can always hit the «Cancel» button, but that could leave the currently downloading file damaged, so use it on your own risk =)
I’ll have to pass my exams the next week, so I already started working less. The next week plan is to upgrade that Connection Wizard dialog and start working on the local webserver feature. (Yeah, I don’t want you to enter that code when ScummVM could do it for you instead.)
Ever since classes ended and I started my exam period (until June 25th), I have been dividing my time between working on the project and studying for exams. It’s been really exhausting, but totally worth it! Here is a recap of what I’ve done:
Add Black/White CLUT8 support to 9patch
Through someqhat of a hack, I have managed to add balck and white support to 9patch, so as to blit into arbitrary MacGui surfaces. So far, I'ts worked great, but I will consider expanding it if/when I need more colors.
Now, it hides the 9patch from the client, and a simple call to loadBorder() suffices to load the appropriate border. However, I still kept the old manual WAGE borders as a fallback, if no border is specified.
Begin work on the engine
Yes! Finally I got to a point wwhere I felt that I could start hacking away at the engine. Following the information on this page and reading the code of other engines (namely WAGE and Drascula), I have managed to get an engine running that:
Can detect Shadowgate (the Zojoi Rerelease).
Can load the menus (although we decided to go with static ones for now).
Can load the window information (bounds, windowtype, id…).
Can load the controls information (enter, exit, hit, go…), although it can’t render it yet, I’m looking on the text drawing code.
It’s been intense, but the more I hack on MacVenture, the more I enjoy it, and the faster I go!
As a last note, I would like to remind of a few things:
My schedule is publicly available at Trello. In the Done section you can see the tasks I consider complete. I try to keep it up to date :)
I have opened a new branch in my repo to hold all things related to the engine.
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.
I hope that the next blog post coming up will be of actual progress we've made. As I said in the previous blogpost, progress has been hindered. That statement wasn't too accurate... a more precise description would have been, progress has come to grinding halt. With the progress I've made before the coding period, after discussing it with my mentors, I focused entirely on studying for my exams and after the last one, I should resume work, which should happen on Monday, hopefully. Screenshots would be due for a proper blogpost, but I have none which I've not showed you already.
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.
Not sure what was the original week plan, but I managed to finish Dropbox and OneDrive storage implementations and add the saves sync feature. And that was a midterm milestone in my proposal plan (mostly because I tried to schedule all the difficult work after midterm as I’m going to have my exams very soon — right before the midterm).
So, now ScummVM knows how to upload and download saves from Dropbox and OneDrive and automatically does that on launch. When I did that, I decided to work on some GUI-related tasks: add an indication icon that is shown when active storage is syncing something, for starters. Well, that took the whole week :D But now it’s an extra nice icon in the corner which automatically appears and disappears when needed. And it’s pulsating when active!
Now I’d work on the GUI further: add a sync progress dialog in save/load manager and forbid using save slots which are being synced. In case I wouldn’t know what to do with the GUI, I can always work on Google Drive storage implementation.
UPD: by the way, I've updated the icon, so now it's completely created by me.
It's been a while since my last post... yet again, although this time at least, it's not entirely my fault. Relatedly, progress has been hindered. I was foolish enough to let my guard down and 'em exams crept up on me. Hopefully they'll soon get off my plate and I'll be able to resume work. Until then, here is a tiny screenshot just to keep you happy, it'll probably be very familiar ^^
The first chunk of graphics code is somewhat ready, sans some "minor" bug fixes in the current codebase, like the piece of code that tells other pieces of code where things are and which way they want to look gets it wrong about half the time. Also if on the off chance you happen to check out the engine in it's current state, you'll notice that the portraits and the ornaments are not shrunk but rather clipped and they are drawn with mismatched colours. After correcting the faulty logic, next up I think will be to add some GUI display. After the GUI is ready enough, character selection should be next up. It'll require further code to handle interacting with the dungeon, with portraits to be specific and also this is where mouse support comes in (which I should have implemented already). After that it's inventory management. This more or less follows my original plan.
For the better part of this week and past weekend, I have been learing a whole lot about surfaces in ScummVM, in order to implement beautiful 9patch borders in the MacGUI code.
As I delved deeper and deeper into the graphics code, I found out that a lot of steps had to be made in order for the 9patch to initialize and blit correctly:
Define the alpha color in a bitmap (a bright pink).
Load the bitmap.
Copy the loaded bitmap into a surface.
Apply the colorkey into the surface (previously defined alpha color).
Pass the surface to the 9patch.
Define the surface in which you want to blit the border.
Blit the border.
Convert the border into the graphics format (I still don’t know how to do this).
Draw the border into the surface you want.
Tell sev that you finally got his code to work, and that it works wonders.
Between each of these steps there are several hours of figuring out which PixelFormats, Palettes, Surfaces and conversion functions I had to use, and several more hours in GDB and the IRC.
But, at last, besides that format conversion in step 8, 9patch is working correctly :)
Below are two images: The border bitmap rendered without going through the 9patch, and after passing it to the 9patch and then rendering (blit) it into surface twice as high and wide (4x size) before printing it to screen.
Edit: I just fixed a small bug, this is what it looks like now:
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.
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.
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.
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 :)
If this sounds like something you would be interested in, please take a look at the
merged list of ideas,
the ResidualVM ideas are at Game Tasks section.
You can also propose projects of your own; we'll be happy to help you shape your idea into a
concrete project. If you want to participate or have questions about GSoC, come talk to us on IRC
Freenode channels #residualvm or #scummvm.
It is hard to imagine a company lasting 25 years, especially one focusing on games, however that is exactly the length of time Revolution Software have been delighting us with their fantastic selection of titles over the last quarter of a century.
To celebrate, in March they are releasing a vast box set with all of their released games and a number of interviews and assets for good measure. This box set also features an addition which has surprised me greatly. They have also included a selection of the enhanced music tracks from Beneath A Steel Sky I created as part of my ScummVM Music Enhancement Project. ‘Flattered’ is certainly the word!
From the official website, they have posted…
To celebrate over a quarter of a century of creating adventure games, we’re proud to announce the forthcoming release of the Revolution: the 25th Anniversary Collection box set on 11th March 2016, exclusively for PC.
As well as featuring each of Revolution’s full roster of games, the box set will also contain comic books, posters, high quality audio tracks, a Broken Sword USB, a digital timeline with extensive behind- the-scenes materials, and two hours of video telling the Revolution story. The video footage features interviews with key team members and our creative partners such as Dave Gibbons, Rolf Saxon and Barrington Pheloung. Revolution official site