Month: June 2012

Tangence

Working on Broken Sword 2.5, I encountered a save bug unrelated to the 32/64 bit portability issue I was intending to look into. The morning after I solved that bug, my laptop (which is also my primary development machine, and only machine with a 64-bit OS installed), suffered fan failure. It is now at warranty services getting repaired, and I have an alternate machine with which to make progress during the 7-9 day estimated turnaround.

Unfortunately, because it lacks a 64-bit OS, I’m unable to test any changes to the Broken Sword 2.5 issue. So, while I wait to get my primary machine back, I will be adding autosave support to a number of engines. I began work on this last night, and already have autosave working for Composer and Hugo engines.

Reconsideration

Upon further examination, the change I was planning to make to Audio::Mixer is not very useful without a related, but very complicated, change to AudioStream (and all of its child classes), that I am not prepared to make. And one of my mentors has informed me that the audio issues I’m encountering are acceptable. In the interest of not completely wasting time while I wait for a change on the status of the graphical solution, I will be working on a different engine in the meantime.

Specifically, it has been brought to my attention that broken sword 2.5 has a saving issue, having to do with serializing/deserializing pointers, that prevents save portability, and is the last blocking issue before the game can be called supported, so I will be looking to fix that while a decision is made on how to proceed with the HE scumm engine graphical issues.

Sound and Light

I have HE engine Scumm games saving at any time now, with only sound and graphical glitches remaining to deal with.

For the sound glitches I am currently working on an interface to Audio::Mixer which will return the AudioStream (or even just the sample buffer) associated with a sound handle, as this will allow engines to get the streams of their active sounds, in order to dump the buffers out to file.

For the graphical glitches, Jakimushka (another student) has already commited code that saves a 16/32 bit screenshot of the display surface, which I intend to make use of to save/restore the graphical state, as soon as the pull request goes through.

Revisionist future

I have heard through fuzzie that there is not global acceptance of my saving anywhere interface design, so I am delaying implementation until I can have a discussion with concerned parties. Unfortunately, I have not heard who those concerned parties are, and they have not made themselves known, so I’ll be sending out an email to scummvm-devel in the near future.

In the meantime, I’ve been looking into expanding the SCUMM engine save format to support additional cases (such as saving HE games through the GMM, instead of only supporting the in-game save menu).

So far these efforts have consisted of debug-stepping the engine loop immediately after making a (currently) buggy savegame, then loading the save and comparing the codepaths to determine what information is missing from the save. I had really wanted to had some code pushed toward this before making this blog post, but this method of research has been very slow-going, and this post is overdue as it is…

I’ll see if my mentors and I can work out a better method tomorrow.