User:AF/SCURK - Revision history

AF: /* TIL - DOS -> Windows conversion */

2026-03-22T10:52:53Z

TIL - DOS -> Windows conversion

← Older revision		Revision as of 03:52, 22 March 2026
Line 53:		Line 53:
	</pre>		</pre>

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

	<pre>		<pre>

AF at 10:52, 22 March 2026

2026-03-22T10:52:17Z

← Older revision		Revision as of 03:52, 22 March 2026
Line 29:		Line 29:
	* Clipping off-by-one:		* 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).		** 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 ===

			<pre>
			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;
			</pre>

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

			<pre>
			typedef struct {
			DWORD dwOffset;
			BYTE height;
			BYTE width;
			WORD wPad;
			} tilShapInfo_t;
			</pre>

			=== 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).

AF: /* Windows SCURK */

2026-03-18T04:28:57Z

Windows SCURK

← Older revision		Revision as of 21:28, 17 March 2026
Line 19:		Line 19:
	== Windows SCURK ==		== Windows SCURK ==

	* The right-most column of pixels on 4x4 objects will end up being partially wiped out upon changing tiles.		* 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)		* 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.		* 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)		* 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)

AF: /* Windows SCURK */

2026-03-13T12:37:03Z

Windows SCURK

← Older revision		Revision as of 05:37, 13 March 2026
Line 19:		Line 19:
	== Windows SCURK ==		== Windows SCURK ==

	* The right-most column of pixels ~~is inaccessible~~ (~~off~~-by-~~one case in various places)~~		* The right-most column of pixels on 4x4 objects will end up being partially wiped out upon changing tiles.
			* 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)
			* 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)		* 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)		* 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)
Line 25:		Line 27:
	** Residential Apartment 1 (3x3) is off-set downwards by one row		** 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.		** 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 ~~far-horizontal extent is~~ off-by-one.		* 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).

AF: sp

2026-03-11T19:21:39Z

← Older revision		Revision as of 12:21, 11 March 2026
Line 24:		Line 24:
	* TILES.DB:		* TILES.DB:
	** Residential Apartment 1 (3x3) is off-set downwards by one row		** 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 ~~subtley~~ shift up by one-row when used in the main game.		** 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 far-horizontal extent is off-by-one.		* Clipping far-horizontal extent is off-by-one.

AF: A bit of formatting.

2026-03-11T19:21:11Z

A bit of formatting.

AF at 10:43, 11 March 2026

2026-03-11T10:43:07Z

← Older revision		Revision as of 03:43, 11 March 2026
Line 14:		Line 14:

	- The base tileset used here is a special MAC-headered MIF.		- 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 is inaccessible (off-by-one case in various places)
			- 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 subtley shift up by one-row when used in the main game.
			- Clipping far-horizontal extent is off-by-one.

AF: Created page with "= 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 ==..."

2026-03-11T10:21:54Z

Created page with "= 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 ==..."

New page

= 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.

← Older revision		Revision as of 12:21, 11 March 2026
Line 7:		Line 7:
	== DOS SCURK ==		== DOS SCURK ==

	- Runway tiles are available for modification and placement.		* 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).		* 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.		* Objects are top-aligned to the empty base tile background.

	== Macintosh SCURK ==		== Macintosh SCURK ==

	- The base tileset used here is a special MAC-headered MIF.		* The base tileset used here is a special MAC-headered MIF.
	- Saved working tilesets use the standard Windows header.		* 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).		* 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 ==		== Windows SCURK ==

	- The right-most column of pixels is inaccessible (off-by-one case in various places)		* The right-most column of pixels is inaccessible (off-by-one case in various places)
	- 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)		* 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)		* 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:		* TILES.DB:
	-- Residential Apartment 1 (3x3) is off-set downwards by one row		** 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 subtley shift up by one-row when used in the main game.		** All other tiles vertically align to the tilebase, however this sets up another off-by-one case where said buildings will subtley shift up by one-row when used in the main game.
	- Clipping far-horizontal extent is off-by-one.		* Clipping far-horizontal extent is off-by-one.