Heyas!!
This is my first post. I've been lurking for just a little while, learning what I can about SCUMMVM and SCUMM itself.
I hope this isn't a double post. I seem to have timed out writing it.
I love SCUMM. Have always loved it. The games are just brilliant and the more I learn about the internals, the more I admire it.
SCUMMVM is one of those projects that I really admire.
As a programmer, I have wanted to learn about SCUMM, SPUTM and iMUSE. I'm interested in more about SCUMM than just client.
However, there really is not much in the way of tools around that I can really use or learn from. Mostly they have disappeared over the years or only support the later SCUMM versions while I'm primarily interested in the earlier ones.
So, to resolve this, I am starting my own side project which heavily depends on understanding and re-purposing portions of SCUMMVM.
I'm not entirely certain that this is the right place to be posting about these kinds of things but there seems to be nowhere else that is really active for discussions about SCUMM.
Anyway, I have a few questions right now and I'm sure I'll have quite a few later on, too and I'm hoping that I can get help here.
My project is (presently) called "SCUMM Explorer" (I know its been used before but I'm hoping my version will be on all platforms, not just Mac) and will get on-going development and support. I also want it to support all SCUMM versions...
I've built a virtual namespace/file system for SCUMM and it uses a kind of plugin architecture for supplying decoding and enumeration. I'm writing it in Pascal... Delphi XE4 and eventually FPC/Lazarus as well. I'm using some features not available to FPC right now but I see no reason for this not to change. Anyway, I'm translating parts of SCUMMVM into Pascal, inside my own framework.
At the moment, I have the bare bones of decoding and enumeration and I've just started on the script decompilation because I thought it might help me better understand the internals. I'm having a bit of trouble about how I should do the decompiling. In particular, the syntax but mostly indirect variable referencing. Getting solid information about the SCUMM internals is very difficult without reading (understanding in completeness) the SCUMMVM code.
I'm starting with SCUMM v2... Would I be able to use the script decompiler utility for SCUMMVM with those old scripts, too - as a reference? I admit I haven't looked at it yet because I was hoping to do something very simple but the indirect and "indexed" or "pointers" features are a bit of a stumbling block. I also got the impression that it would only work for the new versions.
As an aside, I'm also hoping that there might be other people interested in helping with the project. Are there any expressions of interest? The code is very well structured and written (I'm a truly fanatical about it) although the source tree could be better arranged. I could publish it to GitHub for a collaborative effort.
Thanks for your time. I hope I haven't written too much or gone outside the subject rules!
Daniel.
SCUMM utility project
Moderator: ScummVM Team
Hi Daniel,
That sounds interesting, however I have couple of thoughts. First, what is your aim, what feature set are you going to have? E.g. we have ScummEX, there is script decompiler which you mentioned, and unsupported things like ScummC (SCUMM compiler).
Second thing, is that we always warned that people need to be cautious in regards of SCUMM, since LEC lawyers used to be really defensive in regards of their Intellectual Property. E.g. if your goal is to create games based on SPUTM, you're getting into waters of (sub)licensing the engine, which was already sublicensed to Humongous Entertainment.
With current acquisition by Disney, and recent rerelease of LEC titles with use of ScummVM, the things may get changed, but I have no idea as I was never contacted by anyone from Disney.
In my eyes risk of having uncomfortable questions from LEC outweighs fun of working with old and very limited technology, e.g. if your goal is to create games, then Wintermute or AGS could be a much better shot.
Eugene
That sounds interesting, however I have couple of thoughts. First, what is your aim, what feature set are you going to have? E.g. we have ScummEX, there is script decompiler which you mentioned, and unsupported things like ScummC (SCUMM compiler).
Second thing, is that we always warned that people need to be cautious in regards of SCUMM, since LEC lawyers used to be really defensive in regards of their Intellectual Property. E.g. if your goal is to create games based on SPUTM, you're getting into waters of (sub)licensing the engine, which was already sublicensed to Humongous Entertainment.
With current acquisition by Disney, and recent rerelease of LEC titles with use of ScummVM, the things may get changed, but I have no idea as I was never contacted by anyone from Disney.
In my eyes risk of having uncomfortable questions from LEC outweighs fun of working with old and very limited technology, e.g. if your goal is to create games, then Wintermute or AGS could be a much better shot.
Eugene
Heya Eugene.
You have some interesting points.
Firstly, my interests are a little guarded. Like you say, I wouldn't want to infringe on any licensing issues.
I don't really want to do anything that hasn't been attempted before but I do want to do what I want to do more "successfully".
Let me just say that I don't want to create new games based on SCUMM/SPUTM. However, using iMUSE for certain applications was always something I dreamt about but I don't really see that as ever happening in reality. Oh the loss that DirectMusic has caused us...
What I do want to do is learn from the games, however... Its still something of a mine field but I don't intend on re-using them as such.
It certainly sounds odd that you weren't contacted if Disney used SCUMMVM. They could have at least made a courtesy call. I guess they aren't well known for their "bed-side manner"...
The real motivation is curiosity. I'd really just love to be able to "touch" the games in some way, to explore their content and get a better appreciation for what went into them.
I find that there is a big gap in the availability of information and tools to examine the games...
Yes, there is SCUMMEx but from what I can tell, it doesn't really do anything at this point in time. The other problem is that it doesn't handle any of the games I'm interested in at the moment. In addition, if I might say so, its really awful to look at and "use".
Primarily, the features I want are a real "explorer-like" interface and on-the-fly conversion of all resources into "documents" (inside a hierarchical namespace) with live previews.
Additionally, all SCUMM versions should be supported via an extensible architecture to provide the specific decoding logic with incremental improvements.
It has to be "very well written" on top of it all. Pascal, for me, is a must for real "applications". C/C++ is good for "programs" but if you want something that performs reliably, you need a much better run-time and language that adheres more strictly to 3rd gen principles (at the very least).
Anyway, I can provide you with a copy of what I have right now if you're interested in seeing it for yourself.
But back to my original post, I do need help with understanding how to represent the script ops implemented in SCUMMVM using calls to ScummEngine::readVar. The level of redirection is complex and I don't quite grasp how to decompile it at the moment.
Thanks for your reply and concern!
Daniel.
You have some interesting points.
Firstly, my interests are a little guarded. Like you say, I wouldn't want to infringe on any licensing issues.
I don't really want to do anything that hasn't been attempted before but I do want to do what I want to do more "successfully".
Let me just say that I don't want to create new games based on SCUMM/SPUTM. However, using iMUSE for certain applications was always something I dreamt about but I don't really see that as ever happening in reality. Oh the loss that DirectMusic has caused us...
What I do want to do is learn from the games, however... Its still something of a mine field but I don't intend on re-using them as such.
It certainly sounds odd that you weren't contacted if Disney used SCUMMVM. They could have at least made a courtesy call. I guess they aren't well known for their "bed-side manner"...
The real motivation is curiosity. I'd really just love to be able to "touch" the games in some way, to explore their content and get a better appreciation for what went into them.
I find that there is a big gap in the availability of information and tools to examine the games...
Yes, there is SCUMMEx but from what I can tell, it doesn't really do anything at this point in time. The other problem is that it doesn't handle any of the games I'm interested in at the moment. In addition, if I might say so, its really awful to look at and "use".
Primarily, the features I want are a real "explorer-like" interface and on-the-fly conversion of all resources into "documents" (inside a hierarchical namespace) with live previews.
Additionally, all SCUMM versions should be supported via an extensible architecture to provide the specific decoding logic with incremental improvements.
It has to be "very well written" on top of it all. Pascal, for me, is a must for real "applications". C/C++ is good for "programs" but if you want something that performs reliably, you need a much better run-time and language that adheres more strictly to 3rd gen principles (at the very least).
Anyway, I can provide you with a copy of what I have right now if you're interested in seeing it for yourself.
But back to my original post, I do need help with understanding how to represent the script ops implemented in SCUMMVM using calls to ScummEngine::readVar. The level of redirection is complex and I don't quite grasp how to decompile it at the moment.
Thanks for your reply and concern!
Daniel.