Classic Graphics Primitives - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:27:24Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:27, 26 January 2025
Line 1,668:		Line 1,668:

	# Allocate one View structure and one ViewPort structure.		# Allocate one View structure and one ViewPort structure.
	# Allocate two BitMap structures. Allocate two RasInfo structures (linked together), each pointing to a separate BitMap. The two RasInfo structures are linked together as follows: <syntaxhighlight>		# Allocate two BitMap structures. Allocate two RasInfo structures (linked together), each pointing to a separate BitMap. The two RasInfo structures are linked together as follows: <syntaxhighlight lang="C" line>
	struct RasInfo playfield1, playfield2;		struct RasInfo playfield1, playfield2;

Steven Solie: /* ViewPort Display Modes */

2015-11-06T20:42:28Z

ViewPort Display Modes

← Older revision		Revision as of 20:42, 6 November 2015
Line 440:		Line 440:
	HIRES tells the system that the raster specified by this ViewPort is to be displayed with (nominally) 640 horizontal pixels, rather than the 320 horizontal pixels of Lores mode.		HIRES tells the system that the raster specified by this ViewPort is to be displayed with (nominally) 640 horizontal pixels, rather than the 320 horizontal pixels of Lores mode.

	SUPERHIRES tells the system that the raster specified by this ViewPort is to be displayed with (nominally) 1,280 horizontal pixels. This can be used with 31 kHz scan rates to provide the VGA and Productivity modes. SUPERHIRES modes require ECS. See ~~the~~ ~~section~~ ~~on “Determining~~ Chip ~~Versions” earlier in this chapter~~ for an explanation of how to find out if the ECS is present.		SUPERHIRES tells the system that the raster specified by this ViewPort is to be displayed with (nominally) 1,280 horizontal pixels. This can be used with 31 kHz scan rates to provide the VGA and Productivity modes. SUPERHIRES modes require ECS. See [[#Determining Chip Versions\|Determining Chip Versions]] for an explanation of how to find out if the ECS is present.

	LACE tells the system that the raster specified by this ViewPort is to be displayed in interlaced mode. If the ViewPort is non-interlaced and the View is interlaced, the ViewPort will be displayed at its specified height and will look only slightly different than it would look when displayed in a non-interlaced View (this is handled by the system automatically). See “Interlaced Mode vs. Non-interlaced Mode” below for more information.		LACE tells the system that the raster specified by this ViewPort is to be displayed in interlaced mode. If the ViewPort is non-interlaced and the View is interlaced, the ViewPort will be displayed at its specified height and will look only slightly different than it would look when displayed in a non-interlaced View (this is handled by the system automatically). See “Interlaced Mode vs. Non-interlaced Mode” below for more information.

Steven Solie: /* Display Routines and Structures */

2015-11-06T20:41:14Z

Display Routines and Structures

← Older revision		Revision as of 20:41, 6 November 2015
Line 257:		Line 257:
	{{Note\|title=Caution\|text=This section describes the lowest-level graphics interface to the system hardware. If you use any of the routines and the data structures described in these sections, your program will essentially take over the entire display. In general, this is not compatible with Intuition’s multiwindow operating environment since Intuition calls these low-level routines for you.}}		{{Note\|title=Caution\|text=This section describes the lowest-level graphics interface to the system hardware. If you use any of the routines and the data structures described in these sections, your program will essentially take over the entire display. In general, this is not compatible with Intuition’s multiwindow operating environment since Intuition calls these low-level routines for you.}}

	The descriptions of the display routines, as well as those of the drawing routines, occasionally use the same terminology as that in the Intuition ~~chapters~~. These routines and data structures are the same ones that Intuition software uses to produce its displays.		The descriptions of the display routines, as well as those of the drawing routines, occasionally use the same terminology as that in the Intuition articles. These routines and data structures are the same ones that Intuition software uses to produce its displays.

	The computer produces a display from a set of instructions you define. You organize the instructions as a set of parameters known as the View structure (see the <graphics/view.h> include file for more information).		The computer produces a display from a set of instructions you define. You organize the instructions as a set of parameters known as the View structure (see the <graphics/view.h> include file for more information).
Line 760:		Line 760:
	{{Note\|title=WARNING!\|text=It is important to use ''only'' the standard system ColorMap-related calls to access the ColorMap entries. These calls will remain compatible with recent and future enhancements to the ColorMap structure.}}		{{Note\|title=WARNING!\|text=It is important to use ''only'' the standard system ColorMap-related calls to access the ColorMap entries. These calls will remain compatible with recent and future enhancements to the ColorMap structure.}}

	You might need to specify more colors in the color map than you think. If you use a dual playfield display (covered later in this ~~chapter~~) with a depth of 1 for each of the two playfields, this means a total of four colors (two for each playfield). However, because playfield 2 uses color registers starting from number 8 on up when in dual-playfield mode, the color map must be initialized to contain at least 10 entries.		You might need to specify more colors in the color map than you think. If you use a dual playfield display (covered later in this article) with a depth of 1 for each of the two playfields, this means a total of four colors (two for each playfield). However, because playfield 2 uses color registers starting from number 8 on up when in dual-playfield mode, the color map must be initialized to contain at least 10 entries.

	That is, it must contain entries for colors 0 and 1 (for playfield 1) and color numbers 8 and 9 (for playfield 2). Space for sprite colors must be allocated as well. For Amiga system software version 1.3 and earlier, ''when in doubt'', allocate a ColorMap with 32 entries, just in case.		That is, it must contain entries for colors 0 and 1 (for playfield 1) and color numbers 8 and 9 (for playfield 2). Space for sprite colors must be allocated as well. For Amiga system software version 1.3 and earlier, ''when in doubt'', allocate a ColorMap with 32 entries, just in case.

Steven Solie: /* ViewPort Display Modes */

2015-11-06T20:40:33Z

ViewPort Display Modes

← Older revision		Revision as of 20:40, 6 November 2015
Line 432:		Line 432:
	The system has many different display modes that you can specify for each ViewPort. Under 1.3, the eight constants that control the modes are DUALPF, PFBA, HIRES, SUPERHIRES, LACE, HAM, SPRITES, and EXTRA_HALFBRITE. Some, but not all of the modes can be combined in a ViewPort. HIRES and LACE combine to make a high-resolution, interlaced ViewPort, but HIRES and SUPERHIRES conflict, and cannot be combined.		The system has many different display modes that you can specify for each ViewPort. Under 1.3, the eight constants that control the modes are DUALPF, PFBA, HIRES, SUPERHIRES, LACE, HAM, SPRITES, and EXTRA_HALFBRITE. Some, but not all of the modes can be combined in a ViewPort. HIRES and LACE combine to make a high-resolution, interlaced ViewPort, but HIRES and SUPERHIRES conflict, and cannot be combined.

	Set the display mode for a ViewPort by using the VideoControl() function as described in ~~the section on “Monitors, Modes and the~~ Display ~~Database” later in this chapter~~.		Set the display mode for a ViewPort by using the VideoControl() function as described in [[Display Database]].

	The DUALPF and PFBA modes are related. DUALPF tells the system to treat the raster specified by this ViewPort as the first of two independent and separately controllable playfields. It also modifies the manner in which the pixel colors are selected for this raster (see the above table).		The DUALPF and PFBA modes are related. DUALPF tells the system to treat the raster specified by this ViewPort as the first of two independent and separately controllable playfields. It also modifies the manner in which the pixel colors are selected for this raster (see the above table).
Line 448:		Line 448:
	SPRITES tells the system that you are using sprites in this display (either VSprites or Simple Sprites). The system will load color registers for the sprites. Note that since the mouse pointer is a sprite, omitting this mode will prevent the mouse pointer from being displayed when this ViewPort is frontmost.		SPRITES tells the system that you are using sprites in this display (either VSprites or Simple Sprites). The system will load color registers for the sprites. Note that since the mouse pointer is a sprite, omitting this mode will prevent the mouse pointer from being displayed when this ViewPort is frontmost.

	See ~~the “Graphics~~ Sprites, Bobs and ~~Animation” chapter~~ for more information about sprites.		See [[Graphics Sprites, Bobs and Animation]] for more information about sprites.

	EXTRA_HALFBRITE tells the system to use the Extra-Half-Brite mode, a special mode that allows you to display up to 64 colors on screen at the same time. It is described in the “Advanced Topics” section.		EXTRA_HALFBRITE tells the system to use the Extra-Half-Brite mode, a special mode that allows you to display up to 64 colors on screen at the same time. It is described in the “Advanced Topics” section.
Line 454:		Line 454:
	If you peruse the <graphics/view.h> include file you will see another flag, EXTENDED_MODE. Never set this flag yourself; it is used by the system to control more advanced mode features.		If you peruse the <graphics/view.h> include file you will see another flag, EXTENDED_MODE. Never set this flag yourself; it is used by the system to control more advanced mode features.

	Be sure to read the section ~~on “Monitors, Modes and~~ the Display ~~Database”~~ for additional information about the ViewPort mode.		Be sure to read the section the [[Display Database]] for additional information about the ViewPort mode.

	==== Single-playfield Mode vs. Dual-playfield Mode ====		==== Single-playfield Mode vs. Dual-playfield Mode ====

Steven Solie: /* Components of a Display */

2015-11-06T19:47:30Z

Components of a Display

← Older revision		Revision as of 19:47, 6 November 2015
Line 15:		Line 15:
	In producing a display, you are concerned with two primary components: sprites and the playfield. Sprites are the easily movable parts of the display. The playfield is the static part of the display and forms a backdrop against which the sprites can move and with which the sprites can interact.		In producing a display, you are concerned with two primary components: sprites and the playfield. Sprites are the easily movable parts of the display. The playfield is the static part of the display and forms a backdrop against which the sprites can move and with which the sprites can interact.

	This ~~chapter~~ covers the creation of the background. Sprites are described in ~~the “Graphics~~ Sprites, Bobs and ~~Animation” chapter~~.		This article covers the creation of the background. Sprites are described in [[Graphics Sprites, Bobs and Animation]].

	=== Introduction to Raster Displays ===		=== Introduction to Raster Displays ===
Line 252:		Line 252:

	The Amiga has a special-purpose coprocessor, called the ''Copper'', that can control nearly the entire graphics system. The Copper can control register updates, reposition sprites, change the color palette, and update the blitter. The graphics and animation routines use the Copper to set up lists of instructions for handling displays, and advanced programmers can create their own custom Copper lists.		The Amiga has a special-purpose coprocessor, called the ''Copper'', that can control nearly the entire graphics system. The Copper can control register updates, reposition sprites, change the color palette, and update the blitter. The graphics and animation routines use the Copper to set up lists of instructions for handling displays, and advanced programmers can create their own custom Copper lists.


	== Display Routines and Structures ==		== Display Routines and Structures ==

Steven Solie: /* ViewPort Display Memory */

2015-11-06T19:29:33Z

ViewPort Display Memory

← Older revision		Revision as of 19:29, 6 November 2015
Line 489:		Line 489:
	==== ViewPort Display Memory ====		==== ViewPort Display Memory ====

	The picture you create in memory can be larger than the screen image that can be displayed within your ViewPort. This big picture (called a raster and represented by the BitMap structure) can have a maximum size dependent upon the version of the Agnus chip in the Amiga. The ECS Agnus can handle rasters up to 16,384x16,384 pixels. Older Agnus chips are limited to rasters up to 1,024x1,024 pixels. The section on ~~“Determining~~ Chip ~~Versions”~~ ~~earlier in this~~ ~~chapter~~ explains how to find out which Agnus is installed.		The picture you create in memory can be larger than the screen image that can be displayed within your ViewPort. This big picture (called a raster and represented by the BitMap structure) can have a maximum size dependent upon the version of the Agnus chip in the Amiga. The ECS Agnus can handle rasters up to 16,384x16,384 pixels. Older Agnus chips are limited to rasters up to 1,024x1,024 pixels. The section on [[#Determining Chip Versions\|Determining Chip Versions]] explains how to find out which Agnus is installed.

	The example in the following figure introduces terms that tell the system how to find the display data and how to display it in the ViewPort. These terms are RHeight, RWidth, RyOffset, RxOffset, DHeight, DWidth, DyOffset and DxOffset.		The example in the following figure introduces terms that tell the system how to find the display data and how to display it in the ViewPort. These terms are RHeight, RWidth, RyOffset, RxOffset, DHeight, DWidth, DyOffset and DxOffset.

Steven Solie: /* Monitors, Modes and the Display Database */

2014-03-24T19:50:52Z

Monitors, Modes and the Display Database

Show changes

Steven Solie: /* Custom ViewPort Example */

2014-03-24T19:50:29Z

Custom ViewPort Example

← Older revision		Revision as of 19:50, 24 March 2014
Line 1,642:		Line 1,642:
	</syntaxhighlight>		</syntaxhighlight>

	==== Custom ViewPort Example ====		=== Custom ViewPort Example ===

	The following program will create a display with the same attributes as the user’s Workbench screen. It does this by first inquiring as to those attributes, duplicating them, and then creating a similar display.		The following program will create a display with the same attributes as the user’s Workbench screen. It does this by first inquiring as to those attributes, duplicating them, and then creating a similar display.

Steven Solie: /* Monitors, Modes and the Display Database */

2014-03-24T19:43:19Z

Monitors, Modes and the Display Database

← Older revision		Revision as of 19:43, 24 March 2014
Line 1,121:		Line 1,121:
	=== Monitors, Modes and the Display Database ===		=== Monitors, Modes and the Display Database ===

	The graphics library supports a variety of ~~new~~ video monitors, and ~~new~~ programmable video modes ~~not available in older versions of the operating system~~. Inquiries about the availability of these modes, their dimensions and currently accessible options can be made through a database indexed by the same key information used to open Intuition screens. This design provides a good degree of compatibility with existing software, between differently equipped hardware platforms and for both static and dynamic data storage.		The graphics library supports a variety of video monitors and programmable video modes. Inquiries about the availability of these modes, their dimensions and currently accessible options can be made through a database indexed by the same key information used to open Intuition screens. This design provides a good degree of compatibility with existing software, between differently equipped hardware platforms and for both static and dynamic data storage.

	The software may be running on ''A1000'' computers which will not have ECS, on ''A500'' computers which may not have the latest ECS upgrade, and on ''A2000'' computers which generally have the latest ECS but may not have a multi-sync monitor currently attached. This means that there are compatibility issues to consider–what should happen when a required ECS or monitor resource is not available for the desired mode.		The software may be running on ''A1000'' computers which will not have ECS, on ''A500'' computers which may not have the latest ECS upgrade, and on ''A2000'' computers which generally have the latest ECS but may not have a multi-sync monitor currently attached. This means that there are compatibility issues to consider–what should happen when a required ECS or monitor resource is not available for the desired mode.

Steven Solie: /* Run-Time Name Binding of Mode Information */

2014-03-24T19:34:59Z

Run-Time Name Binding of Mode Information

@@ Line 1,512: / Line 1,512: @@
         IDOS->Printf("%s", query.Name);
+    }
+}
 </syntaxhighlight>