Emulators are one of the best things to ever happen to gaming. They can expand your library by tenfold on newer systems. No amount of appreciation would be enough for the hard work of the people who make these (and make them available for free!)
True, but also irrelevant pedantry. Emulators themselves are merely reimplementations of hardware the way ScummVM is a reimplementation of a virtual machine.
SCUMM is (was) the scripting language used to implement game logic in the various Lucasfilm/Lucasarts games. The engine was referred to as SPU (SCUMM Presentation Utility). So it's not like the whole engine was written in SCUMM. Audio, graphics, video, fonts, walkbox handling etc was in native code, of course, and especially in the first games a lot of stuff was hardcoded in the engine.
It doesn't really make sense to call it a SCUMM emulator, ScummVM has a reimplementation of the whole engine.
Of course there's also other engines in ScummVM, some based on the original source kindly donated to us by the developers, but most created by painstaking disassembly.
ScummVM does have emulation for various pieces of audio hardware but that's the only part I would consider emulation.
It's another implementation of the interpreter for the SCUMM language (and by now, some others). If you were to create a new JavaScript or Python interpreter, that also wouldn't be a "JavaScript emulator".
The language is bytecode based, and interpreters for bytecode are also called a "Virtual Machine".
So from a theoretical perspective, what's the difference between an implementation (on different hardware) and emulation?
And when does a game engine, become a language, become a (virtual) machine.
As I understood it, scumm was basically an interpreter, where the instructions don't really bare any resemblance to processor instructions, so a virtual machine is impossible (or the distinction meaningless).
A virtual machine does not have to simulate real hardware. So long as it processes instructions and has a state it can be a VM.
DosBOX is an example of an emulator. It is not an implementation of DOS, it just pretends enough to trick games to run. Emulators usually just translate high level semantics without simulating the real system in any way.
Another way to imagine an emulator - think of a thin layer of software that read Python byecode, and then dynamically translated it to Ruby bytecode on the fly.
This would be neither a Python implementation nor a Python VM - but it would be a Python emulator for the Ruby VM.
But if someone wrote their own Python interpreter, like PyPy, this is a new Python VM implementation.
Scumm as far as I'm aware never existed on ARM, ( or Risc V for the sake of argument), so ScummVM on those platforms are in a sense Python on Ruby.
This is of course hugely muddy. Nim for example can target C and Javascript, neither is an emulator, I'm not sure a 3rd target by a separate developer would be either?
But is Scumm on ARM just a thin layer converting Scumm "bytecode" to ARM machine code? Of course not, it is a full game engine just like on x86.
A true Scumm emulator would translate Scumm script to another game engine like SGI (Sierras game engine), but of course due to the extremely high level nature of these game scripting engines finding direct translations would be near impossible.
I think there's a lot of semantic confusion and industry vagueness going on here - not about OP, more about software generally.
- "Virtual machine" is a term that means a lot of things in different contexts. Your last example refers to hardware or operating system virtualization (VMWare, Docker, things of that nature). These VMs are intended to replicate a full computer system as a subprocess of another (physical) computer system. Typically this is not about replicating the direct hardware details: it would be odd to have an Ubuntu VM with 4GB of RAM directly specified. Rather there is a general Ubuntu VM and the user allocates 4GB of their own memory to the virtualization process.
- "Virtual machine" is also widely used for application
virtualization: the Java virtual machine, for instance, and ScummVM. These VMs are not intended to replicate a full computer and exist to run applications in a way that abstracts away the hardware implementation details. For your second point, "VM" is arguably misapplied to things like JVM and Python VM, but I think the analogy is still useful, and regardless that battle was lost 40 years ago.
In practice "Application Virtual Machine" is taken to mean "compiler or interpreter for general purpose non-native code" but this does not have to be the case. There is nothing inherent about using a more limited set of instructions. Going left-right in terms of processor-level instructions, all of the following can be described as actions using VMs:
using Xen to virtualize a Unix machine - running Debian in Docker - running a web server in Java - scripting in Python - Day of the Tentacle
- An "emulator" is a computer program that models the hardware of another computer system and executes machine language written for that system. An emulator typically carries the hardware specifics of the system it is emulating - in industry emulators are widely used to test new hardware without having to waste physical resources, so having an exact replica is important. For gaming, I suppose it could make sense to double the RAM in an N64 emulator to reduce performance bottlenecks, but it wouldn't be a faithful emulation and would probably be nontrivial to implement without breaking existing games.
I agree that the differences between these are fuzzy. In some sense you can think of an "emulator" as an application virtual machine whose bytecode is the machine language of the hardware the emulator is emulating. I would go so far as to say there isn't a theoretical difference. In practice, the difference is that emulators are used to faithfully run existing compiled applications, including all the unreliable quirks - an emulator that fixes bugs which exist in the hardware is not a good emulator. Application VMs are used to reliably execute new applications (including updates designed to remove unreliable quirks). The use cases and requirements are different enough that I don't think there's much actual confusion.
In another sense emulators are performing hardware/operating-system virtualization into the older system. I think the most salient point is the importance of preserving existing hardware in an emulator. Theoretically you could see someone creating a VM image for KERNAL that can run Commodore 64 8-bit processes on a 64-bit architecture with an arbitrary amount of RAM. But in practice emulators that carry the C64's hardware restrictions are much more useful, since people writing code for C64 hardware typically want to run it on an actual C64.
As one last incredibly pedantic note: there is also genuine fuzziness between OS VMs and application VMs. You can think of the JVM or Python VM as "emulating" a hypothetical processor architecture with Java/Python primitives as fundamental machine-level operations - there used to be physical LISP machines designed like this. Since Java and Python are Turing complete and their bytecode sort of resembles a very verbose assembly, I think the analogy is in fact useful. But this analogy also extends to ScummVM - think of a hypothetical LucasArts arcade cabinet where SCUMM primitives are hard-coded into the processor.
Kidding aside, Curse wasn't too bad, but it wasn't where the original creator(s) intended to go with the story.
And now that Disney owns LucasArts, chances of them supporting a franchise that conflicts with their own Pirates of the Caribbean (one of the inspirations for Monkey Island in the first place) are slim indeed. :(
How come there haven't even been any other games (that I can recall right now) based on pirates and voodoo and traveling between different islands?
I thought the story went that the ride was an inspiration for the game, which was then an inspiration for the movie. I’ve not been on the original ride but some Pirates characters are straight out of the game.
I think it would be supercool if Lucasarts made a “Pirates of the Caribbean and the Secret of Monkey Island” game that is essentially a Monkey Island adventure, somehow incorporating Guybrush, Marley etc in the POTC universe and then giving them a cameo in the next movie.
CoMI ranks very highly on my list. The voice acting and score alone are worth it, but despite the change in director it was still in line with the spirit of the thing. I’ve logged countless play-throughs.
Monkey island 4, though... i’ve only played that through twice.
I do wonder if, for this reason, we're going to see a big uptick into recompilers soon instead of emulators. Creating a modern VM to replace an old VM is great because you can actually improve performance (compile using modern cpu extensions, OpenGL, etc), but reimplemented hardware as software is always going to be slow. It can run fast because hardware now is much faster, but we'll often do things an old cpu could do in 1 cycle in hundreds to thousands of cycles. Clocks haven't changed much in years, so if we're not taking advantage of multithreading or new extensions like we should, newer old systems will be tougher to emu. For the most part new emulators are looking more like VMs too.
I wrote a "scumm restructurer" (scummatlas) that takes the games binaries and outputs all the scripts, room data, etc... In a readable form. And the scummvm documentation and source code was invaluable.
From its home page: "ScummVM is a program which allows you to run certain classic graphical point-and-click adventure games, provided you already have their data files. The clever part about this: ScummVM just replaces the executables shipped with the games, allowing you to play them on systems for which they were never designed! ScummVM supports many adventure games, including LucasArts SCUMM games (such as Monkey Island 1-3, Day of the Tentacle, Sam & Max, ...), many of Sierra's AGI and SCI games (such as King's Quest 1-7, Space Quest 1-6, ...), Discworld 1 and 2, Simon the Sorcerer 1 and 2, Beneath A Steel Sky, ... and many more."
Does anyone have a up to date how to available how to get ScummVM on iOS? The release notes mention some changes to the iOS version. The wiki page [1] is for iOS 7 which is super old. Additionally the whole setup requires downloading some library pack...
I’ve done it semi-recently, but I compiled all the dependencies myself instead of using that library pack since I figured it was probably out of date. It’s tedious but not too bad if you are familiar with cross-compilation. It’s not really something the ScummVM team seems too concerned with since they can’t put the app up on the App Store.
I’m gonna have to compile it again to get all these neat new changes, maybe this time I’ll try to make a Docker container that does all the work.
Now someone get on making Monkey Island 3 please.