[Scummvm-devel] HE games support strategy

Jonathan Gray khalek at linuxgamers.net
Fri Jun 25 11:14:02 CEST 2004


On Fri, 2004-06-25 at 20:35 +0300, Eugene Sandulenko wrote:
> Hi all,
> 
> especially Kirben and khalek.
> 
> There've been rapid progress on latter HE games support, nicknamed HE
> v7.0+. Here I would like to present our strategy. It was hammered
> mainly by me an Kirben, but is good to be archived/discussed and
> presented to khalek and whoever who wants to help us with this giantic
> task.
> 
> The most difficult non-RE question in these titles is exact game
> position in SPUTM engine evolution line. There are some about 50+
> titles, some of which are released with different generation
> engines. So, it is good if we will continue our current route, i.e. go
> from minor versions to major.
> 
> What we saw, the mother of all HE games is DOS version of Putt-Putt
> Parade game. It is went so less from original SCUMM v6, so it's engine

Well the demo anyway (which still used COST), as far as I know all
versions of the full game used AKOS.

> version did not get any HE extensions or changes, only file naming
> scheme was altered and maybe some minor thing like this. After this
> version engine was extended almost for each game, but there are still
> clear classes and games which share same engine. We decided to go with
> two-digits numbering scheme a the moment, and that may not reflect
> original HE versioning which we see in some of their executables. That
> is because often version wasn't changed at all while engine was
> changed enough. A good example of this is 7.0.0 version of Freddi Fish
> 1, which is 640x480 and doesn't run with current ScummVM.
> 
> In scumm_settings table in scumm.c there is a field named heversion,
> and its value is porpagated to ScummEngine object variable
> _heversion. If that game has specific but minor changes, which do not
> deserve bumping _heversion, then new GID should be created and
> assigned to it. But since most engines inherit their predecessor's
> changes it is best to use _heversion rather creating 50 GIDs for each
> game.
> 
> So now on how to determine engine version.
> 
> Present time there are four important reference tables we all have to
> use to determine where this or that game is positioned, thus knowing
> exact target to aim. They are no way are final and may be inaccurate
> even in current content.
> 
>   http://members.optusnet.com.au/scummvm/misc/humongous.txt
> 
>   This table is more or less informational. It contains some strings
> from executables, where we see when this game was released and which
> interpretator version HE attached to it.  What I would like to add
> there is a field with nicks of those who has this particular game,
> size and date of executable, and of course, convert it to HTML.
> 

Actually I just went and de-tabbed a version of this recently and added
a few things (patch interpreters and PJ's Game).

http://khalek.tolmie.net/scumm/humongous.txt

> 
>   http://members.optusnet.com.au/scummvm/he_chart.html
> 
>   In this tables games are sorted in what we believe chronological
> order. Game resolution was determined by test run, so it is
> accurate. VARS type was determined by Kirben by means of quick glimpse
> (he knows the trick), and currently it has 2 kinds of tables. scumm6
> is an unchanged SCUMM vars table, and sputm7.2 is HE's custom vars
> table. But more deep research may show up more differences among
> those. 
> 
> 
>   http://members.optusnet.com.au/scummvm/misc/chart.html
> 

As aquadran pointed out on irc this is a 404, for those who don't know
he meant http://members.optusnet.com.au/scummvm/chart.html

>   This is a huge table of opcodes. It contains just few games. It is
> main source of information which games share same engine and where in
> time they should be positioned. What I saw in the engines, they tend
> to grow with each new version, so having them be sorted by function
> addresses lead us to more or less accurate evolution picture.
> 
>   http://khalek.tolmie.net/scumm/he-md5s.txt
> 
>   This table is new, but I would like to use it more, by connecting it
> with first game. I.e. we will see who has which game and so we may be
> sure we work on _same_ engine for some particular title. Right now it
> has games owned by khalek, but we should consider checking our
> collections, fill spots and add our nicks on titles we own.
> 

I'd like to add the MAXS block version as a means of distinguishing,
While I'm not sure of how correct this is I think its roughly right
The following sizes don't include the 8 byte header.
30 bytes: SCUMM V6/HE V6/HE V70/HE V71
32 bytes: >= HE V72, < Scummsys.9*
38 bytes: >= Scummsys.9*, < C++ engine based titles
44 bytes: C++ engine based titles 

The first two have been worked out, the others haven't.  Its not that
hard to do but it still has to be done.  Unless the MAXS blocks are
decoded correctly the games won't run properly.

> 
> First you check either this game is in huge chart.html. If it's not,
> you should produce appropriate column for it. If you can't do it in
> more that 10 minutes, send request to me, that's quick operation
> here.
> 
> In general we should go from left to right in this table. Right now
> we're at puttmoon.w32 position. We call that version 7.0. See
> he_chart.html table. So if your game is not right next to it (and you
> don't have predecessing games), this should be discussed as it may or
> may not make all development clobberish.
> 
> Then after you determined which game you will be working on, you need
> to determine how big changes are. You have three options: another GID,
> minor heversion change or major heversion.
> 

I think a major scumm version change is unrequired and maybe have
another GID used only if the game is notably different to those near it.

> That is our vision of the subject, your comments are welcome.
> 

Maybe a page also listing how far each title currently gets with ScummVM
CVS would be useful as well.

regards
Jonathan





More information about the Scummvm-devel mailing list