Hi,
On Mon, 28 May 2001 [EMAIL PROTECTED] wrote:
> I've find out that HQ2 fails not due to abscense of memmory
> First of all it call kernel function 0x7a which are identified as
> K_Unknown
Well, 'identified' may not be quite appropriate here ;-)
> The second problem is in vocab.999
> In currect version of VM is is stated that format of this file is the
> same for SCI0 and SCI01 meanwhile format for vocab.999 in KQ1 HQ2 and
> Jones are like in SCI1
OK. Don't think this is a big issue, though, since we're apparently
decoding it correctly already.
> And the third about 32bit version of stack. To do this necessary to
> chage all formats of inmemory objects. I.e. all variables must became
> 32bit instead of 16bit This means that script load function must be
> changed and many of kernel function.
Exactly. Also, this could remove the traditional heap and replace it with
a typed memory model (as explained in PM before).
> Does this really so necessary?
No, it's not strictly neccessary if all we want to do is to add SCI01
support.
> I think that if we use 16byte aligned heapptr and 32bit sp and ip
> counters then we can expand stack up to 1Mb.
I don't think we need that much of a stack. Increasing the heap in this
way is an interesting idea, though; the net memory loss should be
acceptable.
However, we'd still be using a fixed-size heap.
BTW, it is possible (and is common practice) to directly reference stack
data in SCI scripts (e.g. for string operations). This would require some
correction to the 16+4 bit scheme if we really used a 32 bit sp.
As it looks right now, we'd end up using a 32 bit pc, a 16 bit sp, and
16+4 addresses everywhere else (with some way to distinguish between stack
and heap addresses, since string operations could be used for both).
> I don't know game SCI1
> which uses more then 1Mb of memory
Wasn't there something with KQ5 or KQ6 needing 2.2 MB...?
The reasons for the proposal to go to 32 bit are the following:
a) SCI32 will, eventually, require 32 bit support one way or another.
b) SCI itself is strictly untyped, which makes debugging quite a bit
harder. If pointers and values are tagged with type information, we can
check for errors more easily.
c) 32 bit pointers would allow us to keep all scripts in virtual memory
all the time, thereby eliminating the necessity of being present on a
separate SCI heap.
d) Many current processors don't support 16 bit data natively and have an
easier time dealing with aligned 32 bit data.
e) Future SCI games (once SCI studio is completed...) could take advantage
of it.
Re (d): In any case, data should be converted to the processor's native
endianness, which means that we have to iterate over the scripts anyway.
(b) and (c) would simplify the task of debugging our functions by quite a
bit. (c) in particular would also help with execution speed by eliminating
the need to store a copy of a part of the script on the heap (this would
be a moot point if we did script decompression directly to the heap, of
course, but we don't even do run-time resource decompression yet).
I do see the point of your approach, of course. It's more pragmatic than
the 32 bit approach, but it would involve an address / sub-address scheme
similar to the 32 bit approach (untyped, though) anyway, at least on the
pc.
It certainly would be less work to implement. I'm not yet convinced it's
easier to debug and maintain, though...
llap,
Christoph
