outgoing message

a long time has passed since we first met, first knew each other;
since I loved you. in a way, i still do. you have prolonged my life
back in 2001, given me strength to prove to myself what i can be worth
and what i carry within. i can not take this lightly and for all i
have become, all i could have become, you have my eternal thanks.
i would have liked to talk to you again, about our respective directions
in life, about the past, about the things that have happened to us
since our sad parting. my story would surely have fallen short.
i trust that you still carry yourself with the grace that i fell in
love with, so vividly remember, and that you are slowly but steadily
fulfilling your dreams. it is my wish that you do.

love, andreas

the current state of things

A long time has passed since I have posted to this blog, which is rather sad. I have had lots to do and in between exams, illness and SoC hacking there was not much time left to dedicate to keeping the blog up to date, even my training suffered.
Anyway, Dirty D is "prototype done", which means support for SCUMMv5 and code structuring. Its final code formatting is buggy however, so even though the structuring is correct, this is hard to observe unless going into the source and inserting statements to print the various graphs and related meta information which are generated during code structuring. Very much in character of its name and because of lack of time I left it like that to move on to the implementation of the final decompiler in python. (This also meant skipping implementation of a second prototype devoted to the stack based bytecode variants and the question of how to generalize the disassembler portion of the decompiler, but I will come back to that.)
As for "finalD" (it does not have a name yet), it disassembles SCUMM <= 5 currently. The structuring code is next on my agenda to be translated to python, followed by the output. There are a few more days in SoC and I am positive that these things will be finished .. soon :)
There's some beef though and it is related to the stackbased SCUMM variants >= 6. I hope to be able to wrap up the structuring and outputting code fast enough to have time left to devote to these, but the outlook is grim at least for the SoC deadline. Correctly handling these stack based bytecode variants might just require some limited form of data flow analysis, which I have tried to avoid in general. Apart from this, the sheer amount of tedious work involved in writing handlers for opcodes has me cringing in terror by now, at least when deadlines are involved and the optimum outcome until the end of SoC I can envision involves me not sleeping for five days straight.

CRUNCH or How to drain yourself of energy..

These past few days I have worked frantically through the nights to complete Dirty D's opcode repertoir for v5 of SCUMM. I finished up a couple of minutes ago. Nothing beats tediously adding dozens (~107 I believe) of opcode handlers one after another. I will have to think of a way to minimize the pain next time this kind of work comes knocking on my door, which is soon.

Anyway, according to my schedule I was supposed to finish this first prototype, well, yesterday. I currently have an intermediary representation of the raw "disassembled" data. so control flow structure rec. and pseudo code formatting are still missing. The formatting code itself will take about one day, maybe less, and should cover most of the requirements for another bytecode variants as well. (intermediary rep -> pseudo code). The control flow structure rec is what I will write next. I hope to finish all of the remaining work for Dirty D until next Monday so as to not waste much more time before deciding on the nature of the second prototype. Opcode specification probably will be key then, there has to be a less painful way... *rubs his eyes*

good night, for now..

Hacking through the night (Status Update)

It's 5:30 over here. I am somewhat tired after having spent the night hacking on the first decompiler prototype for SCUMM v5 (antipasto "Dirty D") and figured I might just as well whip up a quick status update on my blog. These past few weeks I have been quite busy with university work and personal issues and hence, even though I started writing Dirty D earlier than planned, I find myself barely within schedule now. There are ~10 days until the first prototype "milestone" and my slacker sense alarms me of more sleepless nights ahead. I still have to do the first svk push to my tools branch in the ScummVM repository, but that will happen later today once I am on campus (unless I am run over by a bus or abducted by aliens). Anyway, not too long ago I talked to my mentor about the general design of antipasto. Let me give a quick summary:


The decompiler is planned to roughly consist of two parts.

The first encompasses general utilities to be used to extract/process bytecode from game scripts and bytecode dependent backends making use of these utilities to produce a uniform temporary opcode listing format independent of bytecode variant in structure. All control flow manipulating opcodes of a bytecode variant will have to be replaced by semantically identical counterparts of the temporary format during processing.

The second part holds the control flow analysis functionality of the decompiler. It is responsible for transforming a partial decompilation in temporary format as produced by one of the bytecode variant backends into a semantically identical "program" with low level control flow statements such as gotos resolved into higher level looping/branching constructs where possible.

Rationale:

By disconnecting the control flow analysis part of the decompiler from bytecode dependent decompilation code, we'd go a long way of making the decompiler simpler to extend with support for new bytecode formats. Apart from that, the introduction of a temporary decompilation format might also help make more general ways of specifying bytecode formats in part one of antipasto apparent. Every bit of functionality for initial bytecode processing that can be ripped out of a bytecode variant backend and pressed deep into the guts of Dirty D eases future adding of support for new bytecode variants.

And that's what I'd like.

Report #1 -- Noodles and Double D

Week #1

I have spent most of my first week rereading descumm's source code and prodding my mentor to write up a little document describing SCUMM v5 bytecode format. He delivered it on sunday and it proved to be quite useful for getting a better grasp on descumm's inner workings by just having it side by side with a hex view of one of the Monkey Island 1 game scripts Andreas Muegge was kind enough to send me and descumm's decompilation of said script.

I also started thinking about recognizing control structures within bytecode (from conditional gotos/jumps ..), but as there is more drudgery to do until this becomes relevant I have not yet written up a concise representation of my ideas.

Week #2

I have actually started programming a decompiler for version 5 of SCUMM in Scheme on Tuesday. According to my original project schedule, this wasn't planned to happen for another two weaks while I sketch out an initial design. For this first prototype however, I will heavily lean on descumm's opcode handling code to be able to work on certain improvements earlier.

The prototype is named antipasto and the series of versions I plan to implement will henceforth be referred to as the family of antipasti. The first of these bears the code name "Dirty D" and will essentially be a decompiler for SCUMM v5 with improved control structure recognition in place.

Soon, the work begins..

I have not had much time up unti now to work on my project, much less to blog about it. So: "Hey there, fellow Coders of Summer!" and of course to whoever else is reading this: "Welcome. Wait, what are you doing here?!".

First a small introduction for the folks over at Planet SoC:
My name is Andreas Scholta and this summer I will be working on an improved game script bytecode decompiler for ScummVM. And if that wasn't exciting enough, I will be using Scheme as my language of choice, at least for prototyping that is. Because this is my first time applying for/participating in SoC I do feel lucky and elated for me to have made it this far. Naturally, the blunt of work is still ahead and I hope I am able to successfully complete my project by the end of this summer.

Work is officially supposed to begin tomorrow and hence I have finally taken the time to talk to my mentor about basic project infrastructure things. As a result a SVN branch has been set up and a wiki account was created, which I will use for project internal progress reports and possibly for documentation of specific ideas.

Much thanks goes out to the people who have encouraged me (some indirectly) to take part in this beautiful endeavour and whose silent support up to and loud cheers upon my admission filled me with motivation and a subtle anxiety to finally be able to get to work. You know who you are.

For now, what else is there to say but..
Happy Hacking!

Google Summer of Code

"Dear Applicant,

Congratulations! This email is being sent to inform you that your
application was accepted to take part in the Summer of Code. [..]"

... when that mail appeared in my inbox an hour ago, I screamed for excitement. Accepted! Woooooo! This summer I will be working for ScummVM, writing a new bytecode decompiler for scumm scripts. It will be an interesting experience to say the least :)

Aaaaaaaaaah, this is going to be a beautiful summer!

...

What can I write? I feel speechless and somewhat drained of emotion. It's as if I've spent most of it on the second half of that anime I have been watching the past couple of days: Kanon, the 2006 remake by Kyoto Animation to be exact.

And it seemed like an innocent harem anime in the beginning too... except there was no slapstick humour and its male lead was not a klutz. He was just asshole enough for his harem to react in interesting and entertaining ways. I am no anime blogger and I won't spoil this for you. But heed this warning and don't take it too lightly. If you decide to watch this show, enjoy the first half of laughter and general lightness, but don't let it fool you: soon a series of character centric story arcs will emerge, each sadder than the previous one, gradually working towards a final, devastating attack on your male (if you are male, that is) ego with the obvious goal of making you empty your lacrimal sac under the pressure of overwhelming sadness.

I am spent. I am glad I watched this and I am starting to realize how much I regret having seen it all already. What a ride.. :) Oh! Maybe I should not mention it, but yes, it has a happy end.

Emacs Theme

I wasted today, tweaking David O'Toole's color-theme-cl-frame.el to be more clowney ("colorful"). I will not upload the tweaked theme ever. Ha ha ha.

[update: fugly color-theme-brx.el]

Switching to Google Reader

So, a friend has given me a heads up on some Google Reader developments today: it has improved. Never having tried any previous version, I opened the page, imported my feeds and.. decided to stay.

For now I will keep my Bloglines account, but I can already imagine me trashing it. Bloglines is great, don't get me wrong, but Google Reader has a few obvious things going for it (see Kiko vs Google Calendar).