The International House of Mojo

Yes, an interpreter is just a program that translates higher level instructions (in this case the scripts written in the SCUMM language) to lower level instructions, and executes them at run time.

Obviously, this means that a SCUMM interpreter must be able to: draw primitives on screen, play sounds, manage memory and multithreading and so on.

We are basically saying the same thing, the run-time engine IS the interpreter of SCUMM games (or, if you prefer, the interpreter of the SCUMM games IS the run-time engine).

The JavaScript interpreter in your browser is (almost certainly) written in C++, and executes one by one your JavaScript instructions, after parsing them of course. You can also call it the run-time engine that understands JavaScript instructions, it's literally the same thing and each one is correct.

So yeah, ScummVM coders had a helluvajob to do in order to re-write the interpreter/run-time engine of LucasArts and Sierra games and, yes, I should have said "it does provide modern interpreters of the same old LANGUAGES" in my first post.

Phew, that's it I think. :)
P.S. sorry MrManager for breaking my oath, I'm a terrible person.

The interpreter is just another name for the run-time engine, since the game couldn't run without the engine that interprets the scripts and art.

https://blog.thimbleweedpark.com/tool_names

But that's not the whole of what ScummVM does, as it doesn't just re-create the run-time engine (with all of its hooks to the resources created by the various proprietary tools used in the game creation), but the interactive music engine (iMUSE) and the interactive video engine (INSANE) as well.

The term virtual machine is actually kind of a misnomer in this case. Real virtual machines actually simulate hardware calls to allow a guest operating system to run unmodified, and they require the virtual machine to be run on a system of the same architecture (such as running Windows on an Intel Mac).

http://jpc.sourceforge.net/home_emulation.html

ScummVM, on the other hand, while it's not emulation, is not simulating the entire hardware of a machine either. It converts the graphics and sound code used by a computer or console that ran any particular game into ScummVM's common architecture (although it does include things like the optional MUNT MT-32 emulator).

It actually re-implements the run-time engine (or interpreter), as well as all the hooks to the resources, and any other engine that runs in tandem with the run-time engine. This is why it can be compiled to run on architectures outside of the original system (and even on big endian machines, when the original ran on little endian, or vice versa).

When speaking of such technical aspects, confusion and misunderstandings are always likely :)
Anyway, Aric Wilmunder confirms my theory here: http://www.gamasutra.com/view/feature/196009/the_scumm_diary_stories_behind_.php?print=1
"Since I am talking about the interpreter, let me be specific about what it is. The interpreter was the program that the end-user ran that would initialize the graphics and sounds, read the files from the disk, and interpret the scripts and data in those files to run the game. When we would ship a game we would rename the interpreter to “Monkey.exe” or “Dig.exe”, but during development this tool was called SPUTM, which stood for “SCUMM Presentation Utility (tm)”."

SPUTM IS the interpreter ;)



Haha I swear I won't comment any further, pinky swear! :P

Technically, the executable contains the engine code. The actual run-time engine of the LucasArts adventures is SPUTM - SCUMM is the scripting language (and was the name of the compiler). The scripting language ties all the assets together, but without recreating SPUTM, no LucasArts adventure games would be able to run.

The engines they had to reverse engineer and recreate in LucasArts games were SPUTM, iMUSE, and INSANE (which was used for the biker scenes in Full Throttle). The latter was a real PITA to get working correctly in ScummVM (and in the LucasArts SPUTM implementation as well), from what I read.

You're right about one thing -- you ARE picky. ;-*

And sadly I think your pickiness is right. :~

I may load up the Dreamcast and Wii versions just for fun.

Speaking strictly of LucasArts and Sierra, the executable file was the interpreter of all the resources implemented with their own engine.
So what ScummVM does (again, I'm referring to LEC and Sierra only) is reverse engineering of the interpreters, then the re-creation of a modern version of such interpreters.
The VirtualMachine part of the name says it all. :)

I forgot to do all the testing I planned to do on the last release! Beavis and Butthead Virtual Stupidity. I need to get on it and enjoy these games again and help out these heroes getting these games running again.

They use the same data files, but they have to painstakingly re-create the engines through reverse engineering the executables and data files or re-create them using the sourcecode in the cases where the sourcecode has been granted to them by the license holder.

These types of game projects, in contrast to emulation, actually commonly are called game engine re-creations.

Sorry to be picky, but the nerd inside me must point this out: ScummVM doesn't aim to recreate engines, it does provide modern interpreters of the same old engines, at least for LucasArts and Sierra. :)
Over and out!