Dirty question regarding SCI

Collector · Post by **Collector** » Sun Dec 30, 2012 7:20 pm

There is no difference between the resources for the DOS and Windows versions. The difference is just the interpreter. Sierra designed SCI for external resources to override the ones in the game's archive. This was for making patching easy. Sierra was able to distribute patches that were just the fixed resources that only had to be copied to the installed game's folder. This does not work for a couple of the earliest SCI games. The first release of KQ4 and the first release of LSL2 do not recognize the external resources. Most of the SCI1 games and later will accept the "patchDir" parameter in the RESOURCE.CFG to allow the patched resources to be placed in a subdirectory. Earlier games will only recognize what is in the game's base directory.

The Sierra Resource Viewer's RESOURCE.EXE will extract all resources of the archive that it is used on. The GUI will either extract the resource (File > Extract) or export it to a standard format (Save As...).

Serious Callers Only · Sun Dec 30, 2012 11:55 pm

I'm just looking for possibilities. It's pretty strange that the hack works on the DOS version works on scummvm but the 'windows' one doesn't.

And strange that the gabriel knight interpreter doesn't want to replace it, since it's not one of the early games.

Serious Callers Only · Mon Dec 31, 2012 1:54 am

Actually... is there some kind of cache on the interpreter? That could explain it.

There's a 'RESOURCE.ALT' and 'ALT.MAP' here i'm sadly suspicious of.

edit: it's not a cache, as proven by moving it out of the game; not found blahblah.
However it does contain resources. Possibly some windows version only resources that are used even on DOS but have different names than 100.p56 and 100.v56?

Who knows. Probably scummvm src because it appears to take that into account.

Next step; see if i can open those files.

md5 · Post by **md5** » Mon Dec 31, 2012 2:04 am

Serious Callers Only wrote:Actually... is there some kind of cache on the interpreter? That could explain it.

There's a 'RESOURCE.ALT' and 'ALT.MAP' here i'm sadly suspicious of.

These are the alternate hires resources used in the Windows version of GK1. The reason why the patch is probably not working is that another hires resource (with a different resource ID) is used in the Windows version of GK1. Patching the hires resource will probably not be possible, as the lowres resource you got will have a different resolution

Zeith · Post by **Zeith** » Mon Dec 31, 2012 2:15 am

I checked the RESOURCE.ALT-file and all it contained was a bunch of v56-files and no p56-files. One was called 10100.v56 and was a highres version of 100.v56 (which contains the selections and the cursor).

Edit:
11000.v56 is a high-res version of 100.p56 which is probably the one used by the Windows-version.

Serious Callers Only · Mon Dec 31, 2012 2:20 am

Yes i see it. Pretty funky the dos interpreter is able to use that kind of resolution (the images almost fill my 1366x768 display.

I did try but it refused to replace the image (that btw, changed from 100.p56 to 11000.v56)

It must be checking the size. And the other one too (100.v56 to 10100.v56), that is the menu options itself, probably would break the script coordinates.