1,079
edits
Difference between revisions of "OpenTasks"
→Tools: First go at re-adding bytecode decompiler task. More work needed
(Add draft version of the OpenGL backend task) |
(→Tools: First go at re-adding bytecode decompiler task. More work needed) |
||
| Line 325: | Line 325: | ||
In particular, the user should be able to just drop a file onto the tool icon (or one of its windows), the tool would detect which game it is looking at, and offer a simple "one-click-and-done" start button to the user. Optionally, the user could tweak his default settings before starting the conversion (like choosing a different compression level, a custom output directory, etc.). The GUI would be very forgiving to the user (e.g. if selecting data from a read-only media or a directory with not enough free space, it would automatically ask the user for an alternate output location of the generated files. It would upon startup show a nice friendly window with instructions on how to use it, etc.). The exact desired feature set would have to be determined at the start of the project, in discussions with the ScummVM team members and users on our forums. This would be turned into a rough set of mockups and/or texts describing the planned features. | In particular, the user should be able to just drop a file onto the tool icon (or one of its windows), the tool would detect which game it is looking at, and offer a simple "one-click-and-done" start button to the user. Optionally, the user could tweak his default settings before starting the conversion (like choosing a different compression level, a custom output directory, etc.). The GUI would be very forgiving to the user (e.g. if selecting data from a read-only media or a directory with not enough free space, it would automatically ask the user for an alternate output location of the generated files. It would upon startup show a nice friendly window with instructions on how to use it, etc.). The exact desired feature set would have to be determined at the start of the project, in discussions with the ScummVM team members and users on our forums. This would be turned into a rough set of mockups and/or texts describing the planned features. | ||
Many ideas for what could be done here already exist, but you are most welcome to also develop and contribute your own! | Many ideas for what could be done here already exist, but you are most welcome to also develop and contribute your own! | ||
=== Tools: Game script (bytecode) decompiler === | |||
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:LordHoto|Johannes Schickel]] | |||
''Background:'' | |||
Most (all?) adventure engines ScummVM supports are driven by bytecode scripts, which control the game behavior. For various reasons (in particular, debugging), it's very useful to be able to take such a script and decompile it into something resembling regular code (with variables, loops, if statements etc.). We have a tool for doing this for the bytecode used by SCUMM games. This tool is called descumm. | |||
Currently, descumm use a relatively crude heuristic to detect "if" statements, loops and so on. In particular, it only supports loops with the condition at the start (think "while(...) { ... }" ), not such with the condition at the end (as in "do { ... } while(...)" and also suffers from various other limitations (like not being able to correctly recognize "continue" and "break" statements. | |||
The whole thing is somewhat complicated by the fact that there are two main versions of this bytecode: V5 and older (register based bytecode), and V6 and newer (stack based). | |||
Note: 'This task was [http://code.google.com/soc/2007/scummvm/about.html being worked on] as part of the Google Summer of Code 2007, but the end result sadly is incomplete and never reached a status we are satisfactory with. It is probably best to start from scratch, but you can find the code from then [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/branches/gsoc2007-decompiler/ here in our repository.] | |||
''The Task:'' | |||
Write an improved bytecode decompiler any games using a stack based bytecode system. You can look at existing work from GSoC 2007, our descumm compiler (only SCUMM v6 and newer is stack based) and some other de*.cpp files in our [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/trunk/ tools SVN module]. Initially, support for only one stack based engine's bytecode is needed (e.g. SCUMM v8, as used in Curse of Monkey Island), but everything must be designed and implemented such that it is possible to support other stack based engines. In particular, the final version of the code should support at least one other different bytecode set. Engines which use a stack based virtual machine include SCUMM v6+, KYRA, SWORD1, SWORD2, ... <font color="red">TODO</font> | |||
A good starting point for this might be the [[http://jode.sf.net Jode]] Java bytecode decompiler, the author of which used to be on the ScummVM team. The technical contact has several ideas on how to approach this project, too. | |||
The tool should run on at least Windows, Mac OS X and Linux. Acceptable languages include C/C++, Python, Perl, Ruby -- other languages might be OK, but please consult with us first (after all, other developers also will have to use and maintain your code). | |||
== Engine/game specific == | == Engine/game specific == | ||