Sprite and Layers System Register - Revision history

Ped7g: Ped7g moved page Sprite Control Register to Sprite and Layers System Register: syncing naming with latest nextreg.txt

2020-09-23T20:27:19Z

Ped7g moved page Sprite Control Register to Sprite and Layers System Register: syncing naming with latest nextreg.txt

← Older revision		Revision as of 21:27, 23 September 2020
(No difference)

Ped7g: blend modes change half-documented (waiting for final confirmation it's not a bug but design)

2020-06-10T07:07:29Z

blend modes change half-documented (waiting for final confirmation it's not a bug but design)

← Older revision		Revision as of 08:07, 10 June 2020
Line 45:		Line 45:
	\|}		\|}

	In layer mixing modes (%110 and %111) the "priority bit 7" of Layer 2 colour is propagated through the calculation, i.e. such pixel will raise above sprites even in mixing modes. If either U\|T or L layer contains ''transparent'' colour pixel, the other layer pixel is drawn unchanged (skipping mixing calculation).		In layer mixing modes (%110 and %111) the "priority bit 7" of Layer 2 colour is propagated through the calculation, i.e. such pixel will raise above sprites even in mixing modes. If either U\|T or L layer contains ''transparent'' colour pixel, <del>the other layer pixel is drawn unchanged (skipping mixing calculation)</del> (modified in 3.1.1, precise description to be added).

	Since core3.1.1 the blending modes allow for layer non-contributing-to-blending (use {{NextRegNo\|$68}} to configure blending sub-mode) to show independently in front of sprites.		Since core3.1.1 the blending modes allow for layer non-contributing-to-blending (use {{NextRegNo\|$68}} to configure blending sub-mode) to show independently in front of sprites, but modifies the transparency handling rules (to be documented soon)

	When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[311,248] (inclusively) in sprite coordinates, i.e. the first visible pixel is at X12 coordinate, and last visible pixel is at X22+1 coordinate.		When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[311,248] (inclusively) in sprite coordinates, i.e. the first visible pixel is at X12 coordinate, and last visible pixel is at X22+1 coordinate.

Ped7g: core 3.1.3 changes/refresh

2020-04-13T07:49:32Z

core 3.1.3 changes/refresh

← Older revision		Revision as of 08:49, 13 April 2020
Line 38:		Line 38:
	\| %101 \|\| U L S		\| %101 \|\| U L S
	\|-		\|-
	\| %110 \|\| S (U+L) Colours from ULA and Layer 2 are added (per R/G/B channel) and clamped to 7.		\| %110 \|\| \| since core3.1.1: (U\|T)S(T\|U)(B+L) Blending layer and Layer 2 combined, colours clamped to [0,7]
			<del>S (U+L) Colours from ULA and Layer 2 are added (per R/G/B channel) and clamped to 7.</del>
	\|-		\|-
	\| %111 \|\| S (U+L-5) Similar as previous, but per R/G/B channel (U+L-5) is calculated and result is clamped by 0..7 range.		\| %111 \|\| \| since core3.1.1: (U\|T)S(T\|U)(B+L-5) Blending layer and Layer 2 combined, colours clamped to [0,7]
			<del>S (U+L-5) Similar as previous, but per R/G/B channel (U+L-5) is calculated and result is clamped by 0..7 range.</del>
	\|}		\|}

	In layer mixing modes (%110 and %111) the "priority bit 7" of Layer 2 colour is propagated through the calculation, i.e. such pixel will raise above sprites even in mixing modes. If either U or L layer contains ''transparent'' colour pixel, the other layer pixel is drawn unchanged (skipping mixing calculation).		In layer mixing modes (%110 and %111) the "priority bit 7" of Layer 2 colour is propagated through the calculation, i.e. such pixel will raise above sprites even in mixing modes. If either U\|T or L layer contains ''transparent'' colour pixel, the other layer pixel is drawn unchanged (skipping mixing calculation).

			Since core3.1.1 the blending modes allow for layer non-contributing-to-blending (use {{NextRegNo\|$68}} to configure blending sub-mode) to show independently in front of sprites.

	When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[311,248] (inclusively) in sprite coordinates, i.e. the first visible pixel is at X12 coordinate, and last visible pixel is at X22+1 coordinate.		When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[311,248] (inclusively) in sprite coordinates, i.e. the first visible pixel is at X12 coordinate, and last visible pixel is at X22+1 coordinate.

Ped7g: core 3.0 changes/refresh

2019-11-11T13:18:19Z

core 3.0 changes/refresh

← Older revision		Revision as of 14:18, 11 November 2019
Line 3:		Line 3:
	\|Readable=Yes		\|Readable=Yes
	\|Writable=Yes		\|Writable=Yes
	\|ShortDesc=Enables/disables [[Sprites]] and [[~~Enhanced ULA~~\|Lores Layer]], and chooses priority of sprites and [[Layer 2]].		\|ShortDesc=Enables/disables [[Sprites]] and [[Video_Modes#LoRes_Layer.2FRadasjimian_Mode\|Lores Layer]], and chooses priority of sprites and [[Layer 2]].
	}}		}}
	Bitmapped as follows:		Bitmapped as follows:
Line 10:		Line 10:
	! Bit !! Function		! Bit !! Function
	\|-		\|-
	\| 7 \|\| Enable [[~~Enhanced ULA~~\|Lores Layer]]		\| 7 \|\| Enable [[Video_Modes#LoRes_Layer.2FRadasjimian_Mode\|Lores Layer]]
	\|-		\|-
	\| 6 \|\| If 1, the sprite rendering priority is flipped, i.e. sprite 0 is on top of other sprites (0 after reset)		\| 6 \|\| If 1, the sprite rendering priority is flipped, i.e. sprite 0 is on top of other sprites (0 after reset)
Line 26:		Line 26:
	! Bits 4-2 !! Priority and mixing of layers		! Bits 4-2 !! Priority and mixing of layers
	\|-		\|-
	\| %000 \|\| S L U ([[Sprites]] are at top, [[Layer 2]] under, [[~~Enhanced ULA~~]] at bottom)		\| %000 \|\| S L U ([[Sprites]] are at top, [[Layer 2]] under, [[Video_Modes#Enhanced_ULA\|Enhanced_ULA]] at bottom)
	\|-		\|-
	\| %001 \|\| L S U		\| %001 \|\| L S U

Xalior at 23:17, 19 April 2019

2019-04-19T23:17:24Z

← Older revision		Revision as of 00:17, 20 April 2019
Line 5:		Line 5:
	\|ShortDesc=Enables/disables [[Sprites]] and [[Enhanced ULA\|Lores Layer]], and chooses priority of sprites and [[Layer 2]].		\|ShortDesc=Enables/disables [[Sprites]] and [[Enhanced ULA\|Lores Layer]], and chooses priority of sprites and [[Layer 2]].
	}}		}}

	Bitmapped as follows:		Bitmapped as follows:

Specnext: 13 revisions imported

2019-04-14T10:00:21Z

13 revisions imported

← Older revision	Revision as of 11:00, 14 April 2019
(No difference)

wiki>Ped7g: Fixing info about reversed sprite priority, the technical description (guessed by me) was wrong

2018-12-28T17:26:18Z

Fixing info about reversed sprite priority, the technical description (guessed by me) was wrong

← Older revision		Revision as of 18:26, 28 December 2018
Line 13:		Line 13:
	\| 7 \|\| Enable [[Enhanced ULA\|Lores Layer]]		\| 7 \|\| Enable [[Enhanced ULA\|Lores Layer]]
	\|-		\|-
	\| 6 \|\| If 1, the sprite rendering ~~order~~ is ~~reversed~~, i.e. sprite 0 is on top (0 after reset)		\| 6 \|\| If 1, the sprite rendering priority is flipped, i.e. sprite 0 is on top of other sprites (0 after reset)
	\|-		\|-
	\| 5 \|\| If 1, the clipping works even in "over border" mode (doubling X-axis coordinates of clip window) (0 after reset)		\| 5 \|\| If 1, the clipping works even in "over border" mode (doubling X-axis coordinates of clip window) (0 after reset)

wiki>Ped7g: core 2.00.23 changes

2018-12-28T09:42:27Z

core 2.00.23 changes

← Older revision		Revision as of 10:42, 28 December 2018
Line 46:		Line 46:
	In layer mixing modes (%110 and %111) the "priority bit 7" of Layer 2 colour is propagated through the calculation, i.e. such pixel will raise above sprites even in mixing modes. If either U or L layer contains ''transparent'' colour pixel, the other layer pixel is drawn unchanged (skipping mixing calculation).		In layer mixing modes (%110 and %111) the "priority bit 7" of Layer 2 colour is propagated through the calculation, i.e. such pixel will raise above sprites even in mixing modes. If either U or L layer contains ''transparent'' colour pixel, the other layer pixel is drawn unchanged (skipping mixing calculation).

	When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[~~309~~,248] (inclusively) in sprite coordinates.		When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[311,248] (inclusively) in sprite coordinates, i.e. the first visible pixel is at X12 coordinate, and last visible pixel is at X22+1 coordinate.

	~~[[User:Ped7g\|Ped7g]] ([[User talk:Ped7g\|talk]]) 07:41, December 24~~, ~~2018 (UTC) note the doubled coordinates behave (core version 2~~.00.22 is ~~described above) differently to normal coordinates, for example in X1=X2 case: normal clip window will display one pixel, but doubled coordinates will test X22-1 <~~ X12, ~~so no~~ pixel ~~should be displayed. This inconsistency has been raised in forum, and may change eventually (I would personally expect~~ X22+1 ~~boundary applied, so X1=X2 would produce 2-pixel-wide visible area, or even X22 producing odd-sized areas (up till full 320 sprite~~ coordinate ~~range) sounds reasonable), as new core was not yet released. So the details are "to be confirmed" by final version in published 2.00.22+ core~~.

wiki>Ped7g: disti

2018-12-24T11:09:12Z

disti

@@ Line 17: / Line 17: @@
 | 5 || If 1, the clipping works even in "over border" mode (doubling X-axis coordinates of clip window) (0 after reset)
 |-
-| 3-4 || If %00, ULA is drawn under Layer 2 and Sprites; if %01, it is drawn between them, if %10 it is drawn over both
+| 4-2 || Layers priority and mixing
 |-
 | 1 || Enable sprites over border (0 after reset)
@@ Line 25: / Line 23: @@
 | 0 || Enable sprite visibility (0 after reset)
 |}
 When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[309,248] (inclusively) in sprite coordinates.
 [[User:Ped7g|Ped7g]] ([[User talk:Ped7g|talk]]) 07:41, December 24, 2018 (UTC) note the doubled coordinates behave (core version 2.00.22 is described above) differently to normal coordinates, for example in X1=X2 case: normal clip window will display one pixel, but doubled coordinates will test X2*2-1 < X1*2, so no pixel should be displayed. This inconsistency has been raised in forum, and may change eventually (I would personally expect X2*2+1 boundary applied, so X1=X2 would produce 2-pixel-wide visible area, or even X2*2 producing odd-sized areas (up till full 320 sprite coordinate range) sounds reasonable), as new core was not yet released. So the details are "to be confirmed" by final version in published 2.00.22+ core.

wiki>Ped7g at 07:41, 24 December 2018

2018-12-24T07:41:18Z

← Older revision		Revision as of 08:41, 24 December 2018
Line 27:		Line 27:

	When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[309,248] (inclusively) in sprite coordinates.		When both "over border" (bit 1) and "clipping over border" (bit 5) is enabled, the Sprite clipping window {{NextRegNo\|$19}} '''X-axis''' coordinates are "doubled", and coordinates origin is moved from pixel [0,0] position to sprite [0,0] position ([-32,-32] pixel position). For example: setting clip coordinates as {x1:5, x2:155, y1:7, y2:248} will make sprites visible in area [10,7]..[309,248] (inclusively) in sprite coordinates.

			[[User:Ped7g\|Ped7g]] ([[User talk:Ped7g\|talk]]) 07:41, December 24, 2018 (UTC) note the doubled coordinates behave (core version 2.00.22 is described above) differently to normal coordinates, for example in X1=X2 case: normal clip window will display one pixel, but doubled coordinates will test X22-1 < X12, so no pixel should be displayed. This inconsistency has been raised in forum, and may change eventually (I would personally expect X22+1 boundary applied, so X1=X2 would produce 2-pixel-wide visible area, or even X22 producing odd-sized areas (up till full 320 sprite coordinate range) sounds reasonable), as new core was not yet released. So the details are "to be confirmed" by final version in published 2.00.22+ core.