Hi,
Out of curiousity, I'm reading the technical notes on the SCUMM engine. It's quite a fascinating read, but also very confusing to someone like me, who's not a game developer
These are some of the things I don't quite understand about the SCUMM VM:
- The reference says that every script runs once per frame redraw. Does that mean that every script runs from the first instruction again? Or does the engine keep a program-counter, and increments that after every redraw?
- if the engine keeps a program counter, what happens when the last instruction of the script is reached? Does it just restart the script? Or does it generate an error?
- How is the UI interaction handled within SCUMM? I don't see any mention of signal-functions in the technical reference. How does the game know I clicked "walk" for example? Is the UI-stuff handled in a separate thread?
Some SCUMM questions
Moderator: ScummVM Team
I am not a SCUMM engine developer myself, but most of your questions should be clear if you read the code in:
https://github.com/scummvm/scummvm/blob ... script.cpp
As for the threads question, we don't generally use threads.
DOS era programs used earlier versions of multitasking / multiprogramming as the PC had a single CPU...:
https://en.wikipedia.org/wiki/Computer_multitasking
https://en.wikipedia.org/wiki/Schedulin ... 29#Windows
https://github.com/scummvm/scummvm/blob ... script.cpp
As for the threads question, we don't generally use threads.
DOS era programs used earlier versions of multitasking / multiprogramming as the PC had a single CPU...:
https://en.wikipedia.org/wiki/Computer_multitasking
https://en.wikipedia.org/wiki/Schedulin ... 29#Windows
To answer your questions:
- There is a program counter / instruction pointer for each script. In each cycle, this counter is updated accordingly, so the engine knows the current instruction, as well as the state of the currently running script (i.e. its local and any global variables, shared among all scripts, such as the current room)
- Usually, there is a main script either for the whole game, or for the current room. This script has its own loop that stops under certain conditions (e.g. the player exits the room). So, there is always at least one script that's running in the background. There are also ephemeral scripts, that are only used once and then stop. For example, a script that checks where the user clicks in a room may run continuously until the user exits that room. On the other hand, a script that handles player movement from point A to point B only runs while the sprite is walking, and then stops.
- As mentioned, UI handling is usually done via a script that keeps running while the player is in a room and handles all the UI logic in that room
- There is a program counter / instruction pointer for each script. In each cycle, this counter is updated accordingly, so the engine knows the current instruction, as well as the state of the currently running script (i.e. its local and any global variables, shared among all scripts, such as the current room)
- Usually, there is a main script either for the whole game, or for the current room. This script has its own loop that stops under certain conditions (e.g. the player exits the room). So, there is always at least one script that's running in the background. There are also ephemeral scripts, that are only used once and then stop. For example, a script that checks where the user clicks in a room may run continuously until the user exits that room. On the other hand, a script that handles player movement from point A to point B only runs while the sprite is walking, and then stops.
- As mentioned, UI handling is usually done via a script that keeps running while the player is in a room and handles all the UI logic in that room
Hi,
Thanks for your reply, but the sourcecode is not exactly a good reference guide on how the engine works internally.
And regarding the second question: SCUMM does have cooperative threads (managed by the engine). I assume this behaviour is emulated by ScummVM too. I'm just trying to understand how the SCUMM threads work together with the interpreter.
Thanks for your reply, but the sourcecode is not exactly a good reference guide on how the engine works internally.
And regarding the second question: SCUMM does have cooperative threads (managed by the engine). I assume this behaviour is emulated by ScummVM too. I'm just trying to understand how the SCUMM threads work together with the interpreter.