[virtmach] Your VM
Mickaël Pointier
virtmach@iecc.com
Mon, 28 May 2001 10:46:22 +0200
> > > So, why do you think VM with it's own code was a better implementation
> > > option for Creatures than say interpreter, or encoding behaviour of
your
> > > objects over some domain-specific library? ;-)
> >
> > Hum.
> > What is the difference between a VM and an interpreter ? For me a VM
> > is a "byte code interpreter", so I do not understand the distinction.
>
> Hmmm... In my mind a VM is is a much lower abstraction than an
> interpreter.
> like SNES9X is a VM and perl is an interpreter. If the VM/interpreter's
> ops can be easily translated to silicon then its a VM, otherwise
> its an interpreter...
Ok, looks reasonable.
I would like to have the oppinion of everybody around here about what
would be the "ideal" design of this kind of system for a game.
Typically, games run on a large kind of various hardwares (from PC that
have powerfull processors and caches to some game consoles that have
almost no cache and very slow random access memory (but have fast
DMA and linear access)), on various operating systems, with variables
number of registers, and so on...
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.
I personaly think that if the interpreter is well coded, if the design of
the
language is between CISC and RISC (to avoid having to much instructions
that will trash the cache, or too few instructions that would result in the
need to execute a lot of micro instructions), then it would be possible to
have decent execution speed, thus having the advantage of having a data
driven game => possible to update game logic without having to recompile
the core engine code, and a light weight game engine due to the fact that
the game logic is in the script, ...
I wonder what are the most often used methods to execute binarised code
at run time: State machines, large switch case statement, memory alligned
data, or byte packed informations... how the coupling between scripting and
core engine functionality is done, how storing variables, communication
between scripts, and so on.
I already have some experience with all that, but I would like to have other
people view on that subject.
Thanks in advance !
Mickael Pointier