User:AF/SCURK: Difference between revisions

From sc2k-reverse
Jump to navigationJump to search
AF (talk | contribs)
m sp
AF (talk | contribs)
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).

Revision as of 05:37, 13 March 2026

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