On Feb 16, 1:39=A0pm, aiiad...{at}gmail.com wrote:
> On Feb 15, 5:48=A0pm, BLuRry  wrote:
>
> > I don't know what kind of overhead it would take for the //gs to
> > handle all the conversions mentioned, but it seems that some sort of
> > dynamic recompilation might be more in order. =A0
>
> What is included in the game files?
>
> guesses:
>
> background graphics...
> moveable sprites
> music/sounds
> boundaries of character movement
> removable boundaries (IE a door you can go through once open)
>
> text from characters, rooms, item descriptions
> timeline events (IE, this happens at time X)
> trigger events (when player does X, Y happens)
> standard text adventure text
>
> ---------------------------------------------------------
>
> graphics are easily converted. =A0For now, who cares if they look good.
> just get the stuff on the GS screen. =A0Same for sprites, and boundaries
> can be scaled to fit the GS screen. =A0Music is easily converted.
>
> It seems like porting a game interpreter like this would be fairly
> easy.
>
> Rich

Details on LucasArts SCUMM format here:
http://alban.dotsec.net/9.html
http://scumm.mixnmojo.com/

Details on Sierra's AGI format here:
http://www.agidev.com/projects/nagi/

I dunno -- both formats are pretty detailed and use a ton of ram and
CPU since they're interpreted.  When you consider you want things to
be fast (meaning loading from disk as little as possible and not
having to perform on-the-fly conversion), it makes sense to pre-
process things a bit.  At that point, why not make a 65816 recompiler
that converts the games to a native, optimized format?  Think of it as
being to SCUMM what a basic compiler is to Applesoft. :-)

-B
--- SBBSecho 2.12-Win32