Torin's Passage: I can't find 'global91' definition in SCICompanion

[Kawa]

And I couldn't figure out how to add that, I'm afraid.

[Collector]

Perhaps if Phil sees this he might be able to point you in the right direction.

[lskovlun]

And I couldn't figure out how to add that, I'm afraid.

Saving changes to an SCI32 game might be a bit more difficult, because there's a third file, resmdt.xxx - and to my knowledge nobody has quite figured out what to do with it. ScummVM works without it, as does Companion if you rename the other two files. Since it's the same size as the resmap file, it's probably going to have the same data sorted by a different key, perhaps, but the map entry format looks different as well. It's been a while since I looked at it.

[EricOakford]

And I couldn't figure out how to add that, I'm afraid.

Saving changes to an SCI32 game might be a bit more difficult, because there's a third file, resmdt.xxx - and to my knowledge nobody has quite figured out what to do with it. ScummVM works without it, as does Companion if you rename the other two files. Since it's the same size as the resmap file, it's probably going to have the same data sorted by a different key, perhaps, but the map entry format looks different as well. It's been a while since I looked at it.

That could explain why, after making changes to the SQ6 demo to make my SCI32 template, Companion would later erroneously detect the resource.map format as SCI1, rather than SCI2. I'd have to manually change this to the correct SCI2 every time I wanted to make changes.

[OmerMor]

Saving changes to an SCI32 game might be a bit more difficult, because there's a third file, resmdt.xxx - and to my knowledge nobody has quite figured out what to do with it. ScummVM works without it, as does Companion if you rename the other two files. Since it's the same size as the resmap file, it's probably going to have the same data sorted by a different key, perhaps, but the map entry format looks different as well. It's been a while since I looked at it.

Hi Lars,
I have found this piece of documentation for MAKEVOLS which might help:

MAKEVOLS.EXE
Version 5.00


Purpose:
Combines a game's resources into one composite volume.  In addition to the resource volume, a map file of offsets and a map file of resource date/times are generated.  The offsets map file is used by the game for locating resources within the volume.  The date/times map file is only needed when re-running MAKEVOLS in Update mode. 

   
So probably we should not worry about RESMDT.

[lskovlun]

So probably we should not worry about RESMDT.

Ah thanks, it's interesting that they ship it then. But it's a small file, so including it doesn't hurt I guess.

[EricOakford]

What, no RESSCI.000? You need to rename that too (to RESOURCE.000).

OK. I did not rename the actual resource volume as without knowing about the workings of the map file I assumed that it would be looking for RESSCI.000. Even though Companion was not intended for these later games, this is one change that would be nice to have; to allow Companion accept the different naming conventions.

Yeah, being able to accept other naming conventions would be a good idea. There's also the Macintosh SCI1.1 and SCI32 games, which use yet another naming convention - the resource files are labeled "Data1", "Data2", etc. From what I can tell by looking at them in ResEdit, they store all of the resources in their resource fork, and they have no data fork.
While neither Companion nor SCI Resource Viewer can open these resource files, ScummVM can, so it can play those games.

[Kawa]

Opening a game in SCI Companion is complicated enough as it is. I'm not gonna try again.

[lskovlun]

There's also the Macintosh SCI1.1 and SCI32 games, which use yet another naming convention - the resource files are labeled "Data1", "Data2", etc. From what I can tell by looking at them in ResEdit, they store all of the resources in their resource fork, and they have no data fork.

A number of Macintosh games have a Mac-specific icon bar system. Full support for them would be nontrivial.

[EricOakford]

A number of Macintosh games have a Mac-specific icon bar system. Full support for them would be nontrivial.

Oh, right, I overlooked that. They also use the Mac OS save/restore dialog instead of the SCI one. I don't think ScummVM uses those anyway.

The only reason I liked the idea was so I could extract the resources from the Mac version of QFG1VGA and compare them to the DOS version. That's because I plan to make a patch that, among other things, includes the Mac version's bug fixes.

[Kawa]

Does ScummVM's diskdump * debugger command not work on Mac games?

[lskovlun]

You'd likely have endianness problems if you managed to get the data into Companion. At a cursory glance, it seems diskdump would fail to save the Mac icon bar resources because they don't have a corresponding file extension on the PC side.

I was asked to look into that Pharkas Mac easter egg years ago. I think someone sent the disassembly to me (Omer?) and I did the decompilation manually. The disassembly probably came from SV (and had endianness problems as I recall).

EDIT: Thread here: http://sciprogramming.com/community/index.php?topic=1584.msg10916#msg10916

[Kawa]

Well, true on the icon bar resources thing but if it's bugfixes you want...