Add support for Iff 1.0 to Volcanic for SPR# Chunks

[JDrocks450]

Brief
Add support for viewing IFF v1.0 in Volcanic. Supported chunk types are: SPR#, BHAV (wip), STR.

Sprites

Z-Buffers

Sprites that are not inherently objects can also be viewed by using the 'Frames/Rotations' button on SPRResourceControl to view them as frames and not interpreted as an object

Exported Sprites

BHAV (wip)

Video
Here is a recorded video demonstrating how the submission works (OneDrive)

Changes Summary

• Add support for IFF 1.0 Header
• Add SPFResControl for viewing SPF# chunks
• Modified STR chunk reader to use parent IFF file version to read strings from Steering Commitee IFF files
• Add Grayscale PALT by default instead of all black
  • Add contructor overload for PALT to allow for manually-built color palettes (unused as of now)
• Modified Toolstrip Items for loading External Iff in MainWindow.cs to support Iff & Spf and added a special dialog for loading both at once into a GameObject.
• Modified IFFResComponent to support SPR# resources using the SPRResControl
• Added methods in SpriteEncoderUtils to support SPR# resources

All of these changes isolate themselves from any existing functionality and use the existing functionality as a baseline to implement the new features to remain consistent.

[riperiperi]

Gave this a shot, there are some issues getting it working: you didn't include changes to the csproj to add your new classes, and it appears to be reading the rsmp offset in v1 iff which breaks reading them entirely.

It's a bit weird providing the OBJD view for external iffs when it relies so heavily on loaded content. Trying to use OBJD view on steering committee iffs tends to display loaded TS1 objects in the OBJD/DGRP views rather than the external object (it attempts to spawn them in the VM by GUID), which is why I originally limited it to the resource viewer only.

Also - it might be useful automatically reading NAME and XXXX chunks and converting them to iff 2.0 chunk names, though I'm not entirely sure how those chunk types work.

[riperiperi]

This isn't present on v1.

[riperiperi]

This should probably be removed - there's no case where this is useful.

[citrusella]

Also - it might be useful automatically reading NAME and XXXX chunks and converting them to iff 2.0 chunk names, though I'm not entirely sure how those chunk types work.

Okay, I removed what this said before because I had more time to sit down with multiple NAME chunks, and they're one of the following two formats as far as I can tell:

• 8 bytes of 0 (I imagine like some other chunks this might be four bytes of 0 and then four bytes of a version and it happens to be 0)
• EMAN (little endian NAME)
• 4 bytes (little endian) representing number of entries in the chunk
• Entries
  • Four byte little endian identifier that allows the label to be connected to the chunk that contains the same (big endian) identifier at the end of its header
  • Null-terminated ASCII string of label contents

OR it immediately starts with the entries (I've only seen this in one spf so far, for floorlamp1/its corresponding changed filename in the 1999 beta)

• Four byte little endian identifier that allows the label to be connected to the chunk that contains the same (big endian) identifier at the end of its header
• Length-prefixed ASCII string (one byte for length followed by the label contents)

1.0 iff chunks that don't have a label end their header with FF FF FF FF. It is possible for a NAME chunk to contain unused names under some circumstances, though I mostly say this because the object I manually converted (floorlamp1, the one that visually matches Halogen Heaven from the base game) had one string resource (the attribute labels) that appeared to be unlabeled (without clearly being intended to be unlabeled)... but it clearly had an entry in the NAME chunk... except that the identifier in the strings' header didn't match the identifier in the NAME chunk... for some reason. So Steering Committee Edith didn't see/use it.

I have no idea about XXXX except that it almost seems to contain garbage data intended to be removed/no longer read? https://web.archive.org/web/20220426023147/http://simtech.sourceforge.net/tech/info_resources.html describes it as a "filler pseudo-resource". Which might also imply it's a chunk type that can/does exist in some 2.0/2.5 iffs? ...I've never looked at 2.0/2.5 iffs enough in a hex editor to know that... (I left it out of the lamp conversion I did and the lamp turned out fine.)