User:AF/SCURK

SCURK Observations

Various observations concerning the different versions of SCURK.

This will also highlight certain pitfalls and "gotcha" cases when it comes to WinSCURK.

DOS SCURK

• Runway tiles are available for modification and placement.
• The palette that you get here isn't a one-to-one match when it comes to WinSCURK (see more detail under the Windows SCURK section).
• Objects are top-aligned to the empty base tile background.

Macintosh SCURK

• The base tileset used here is a special MAC-headered MIF.
• Saved working tilesets use the standard Windows header.
• If you do a standard save of the base object set, certain palette indices are not preserved (glaring examples would be the Marina and Load Bay).

Windows SCURK

• The right-most column of pixels on 4x4 objects will end up being partially wiped out upon changing tiles. (This appears to be an underprocessing anomaly when it is rendering the shape to Dib/Graphic)
• The left-most column of pixels on 4x4 objects will always be wiped out upon changing tiles. (perform a fill operation on a 4x4 tile and then switch to another and back to see this effect) (This occurs within the function that re-scales/shrinks the image - more under-processing)
• Adding any painted pixels to the top-row will result in the shape being pushed down by one-row upon switching to another and back.
• Tilesets converted from DOS are off-set downwards by one row (the bottom row of the active tile ends up truncated upon view/change/interaction) (However when used in-game - aside from the bottom row truncation - their Y-position is correct)
• The Plymouth Arcology suffers from some bizarre clipping cases on both the farthest left and right-hand sides within the top left/right portions of the tile base. (this is a more general problem for 4x4 objects)
• TILES.DB:
  • Residential Apartment 1 (3x3) is off-set downwards by one row
  • All other tiles vertically align to the tilebase, however this sets up another off-by-one case where said buildings will subtly shift up by one-row when used in the main game.
• Clipping off-by-one:
  • Right-most one-pixel over-clipping was occurring in non-maxwidth cases - this should only happen once the maximum valid width (what you see when the clipping boundary is enabled on the Macintosh version is correct).

TIL - DOS -> Windows conversion

typedef struct {
	BYTE largeArc[12];
	DWORD dwLargeSize;
	BYTE largeHed[12];
	DWORD dwLargeOffset;
	BYTE otherArc[12];
	DWORD dwOtherSize;
	BYTE otherHed[12];
	DWORD dwOtherOffset;
	BYTE smallArc[12];
	DWORD dwSmallSize;
	BYTE smallHed[12];
	DWORD dwSmallOffset;
	BYTE urkTextFile[12];
	DWORD dwUrkTextOffset;
	BYTE readOnlyFile[12];
	DWORD dwReadOnlyOffset;
} tilHeaderStruct_t;

It should be noted that not all TIL containers happen to contain the readOnlyFile; due to that it's likely best to check for READONLY.XXX specifically if you're then going to jump to its offset position; otherwise the most common last file will be URKNAME.TXT and then its offset.

typedef struct {
	DWORD dwOffset;
	BYTE height;
	BYTE width;
	WORD wPad;
} tilShapInfo_t;

Mac and DOS -> Windows Palette

Both Mac and DOS make use of the same palette; if the built-in Mac tileset resource is extracted from MacSCURK it can utilize the generated DOS palette indices in WinSCURK (if programmed to do so - it isn't by default).