[virtmach] Your VM
Tue, 29 May 2001 10:37:38 +0100
> A lot of people in the game industry think that doing most of the
> game logic using scripting of any kind is bad, because it's very
> slow at run time.
The bulk of the execution time of a game, is not, in my experience, in "game
logic", but in things such as render loops, physics, and navigation. None
of which are tightly coupled to game logic, or written in a scripting
language. A well supported highlevel scripting language is not in my
experience, a significant runtime overhead, and confers some significant
> large switch case statement,
An unmaintainable nightmare. This was the implementation of choice when I
joined the project, but it was becoming unmanageable, so was reimplenmented
as a dispatch table.
> memory alligned data, or byte packed informations...
The new VM uses 32 bit instructions, where the first byte is the instruction
(dispatch table index, 0-255, no range checks) and the next three bytes are
the operands, typically, but not exclusively, 8 bit stack addresses (loosely
3-address model). Not that each and every 32 bit word in the
program/executable block is an instruction, which permits additional
link-time optimisation, and program correctness checking (the VM can detect
almost every possible case of malformed code coming out of the compiler).
> how the coupling between scripting and core engine functionality is done,
The native functions are called via a single instruction (GFC - "Global
Function Call") which dispatches on a string, which is mapped to a object
pointer in a once-only "link time" lookup. Native functions are implemented
by deriving from a common base class.
> how storing variables,
Temporary variables on the per-execution stack, permanent variables in
per-agent storage, constants in per-script constant data block.
> communication between scripts,
Message objects, 'bindings' (pointers to agents), parent/child agent
relationships, and public access areas of per-agent storage.
Beasts Team, Creature Labs Ltd