resource.00x limitations

[doomlazer]

I'm packing every possible SCI background pic and overlay from the different KQ4 versions into a single project and starting to get concerned about possible resource file limits. As a precautionary measure I'm now putting backgrounds into a new resource file, but are there any known limits for these files other than FAT file limits (which I'm nowhere near) or disk/media storage limitations? I believe resources are loaded as needed, so I'm not expecting memory to be a problem, but I also don't want to paint myself into a corner here.

Thinking a bit more broadly, what are the other factors that limit maximum resource usage. Forgetting heap, I would assume the hard limit for maximum of any particular type of resource to be 999, but that should be about it, right?

You could theoretically get around that limitation and create massive games, by having a second 'game' that could be transitioned between using saves. Unfortunately with a game that large, or one that even approaches the 999 limit, the bottleneck would probably be inventory items, which always exist in SCI0 heap. I'm not planning to build anything on that scale, so feel free to ignore this paragraph as daydreaming.

[Kawa]

To quote my blog post on the subject:

The resource.map file specifies which resources can be found on which disks. For SCI0, it’s a list of six-byte entries. The first two encode the type (upper five bits) and number (the lower 11 bits), the next four have the volume number (upper six) and absolute offset in the volume (the rest). If a resource appears on multiple disks, it’s listed once for every appearance. In SCI01, there are only four bits for the volume number, trading amount for space.

In the later versions, the map file starts off with a list of offsets for each type listed in the map. With this list and a contract that the map entries are sorted by type, the interpreter can look up a given type of resource much faster. Since we already know that this part of the list only contains resources of a given type, we can use the full 16 bit range for the numbers. In SCI1, the next four bytes are just like in SCI01. In SCI11 however there’s only three, and there’s no volume number. Then in SCI2 it’s a straight-up plain 32 bit offset value.

Basically then since SCI0 games were designed to be played from diskettes, they traded some bits of the "where in the volume is it" for "which volume is it in". With four bytes or 32 bits, that means you'd have a maximum possible offset-in-volume of 4,294,967,295 bytes. But if you use six of those for the disk number, you get 64 diskettes to use with a maximum offset-in-volume of only 67,108,863.

On top of that, the resource map in SCI0 can specify 32 different types of resource, with an upper bound of 2048 each. But since the filename format is restype.num you end up with a limit of 1000 resources of each type.

With SCI11 using a 24-bit offset-in-volume value and no which-volume value at all (there is only resource.000), you get an upper limit of 16,777,215, and in SCI2 onwards it's the full 4,294,967,295 again. Since the filename format has switched around, we can now express and use the full 16-bit range for resource numbers.



So to simplify, 999 is a hard limit because of file names, but in that same SCI engine another hard limit is 2048 because of map formats.

[doomlazer]

Great, thank you for the detailed information.

Creating a new custom resource type with the intention of making room for an additional 999 pics, views, or whatever wouldn't be possible without some major hacks, right? SCICompanion couldn't rebuild the resource even if you could get the interpreter to use the new type as an existing one.

There is just something appealing to me about the idea of doubling or tripling that 999 limit, but I wouldn't want to do it at the expense of losing compatibility with SCUMMVM or DOSBox. You could potentially combine several other full games inside of one project

[doomlazer]

I'm overthinking this. I still have tons of room. I could likely still fit another SCI0 game in there if the system scripts were compatible.

[Charles]

To quote my blog post on the subject:

[In SCI0] you get 64 diskettes to use with a maximum offset-in-volume of only 67,108,863.

With SCI11 ... you get an upper limit of 16,777,215, ...

and in SCI2 onwards it's the full 4,294,967,295 again.

Those offsets relate to byte size, right? So that gives us maximum RESOURCE.000 sizes of:

• SCI0 = 2^26 = 64MB
• SCI11 = 2^24 = 16MB
• SCI2 = 2^32 = 4GB

... wait, is that right? SCI0 can have larger resources than SCI11?

[Kawa]

... wait, is that right? SCI0 can have larger resources than SCI11?

No, that's the size of one entire volume. Individual resources have their own maximum sizes (a page perhaps), and then there's the 1000-per-type limit. And on top of that, the SCI0 volumes were meant to be split into diskette-sized chunks anyway.

The trick with SCI11 is that the digital audio need not be in the same volume as the rest of the game, hence Freddy Pharkas has a 5.23 MB resource volume but 15.9 MB digital sound effects and 572 MB audio36 volumes.

(also, SCI0 can't have RESOURCE.000. It starts at 1)

Edit: A rhetorical question comes to mind. Is 16 MB of non-audio resources a hard limit on SCI11?