DISPLAY DRIVERS =============== Introduction: Computer graphics on the Amiga and graphic cards ------------------------------------------------------------- Here are just a few words on the differences between planar and chunky graphic organisation which have already been discussed within the chapter on graphic formats. "Planar" On the Amiga, with its original graphic chipset, the graphic data is principally organised in the form of single planes. With ECS these are max. 6 Bitplanes (0..16/32 Colours or HAM6), with AGA then max. 8 Bitplanes (0..256 Colours or HAM6/HAM8). These planes have to be understood as the single levels of the bytes, which contain the number of the colour registers to be used. So bitplane 0 contains "one after the other" the lowest and bitplane 6/8 the highest bits of these bytes. The reason for this is how the custom chips of the Amiga work. Also certain advantages in speed which will appear when using less than 256 colours (for example only 63 or 128). With chunky modes this does not matter since 8 Bits per pixel (1 Byte) will always be used in contrary to the planar mode where only as many bytes as actually needed (1-8) will be used. Additionally, at least two ways exist to represent data as bitplanes. The first one is just called "planar" (from "plane"). The second one is "interleaved", since the lines of the single planes do not follow each other but instead are interleaved together. This has just been mentioned for reasons of completeness - and because it is a special feature of the AGA chipset: for more information you should read specialised literature. "ChunkyPixel" The ChunkyPixel representation of graphics is the most simple of all and in most cases where 256 colours are to be displayed perhaps also the fastest one. There's not much to say about this one, the colour register numbers will simply be stored line by line - as much as needed. Depending on the width and height of the graphics, these are written from left to right and top to bottom into a rectangle memory area which in the best case would be identical with the graphic memory of an optionally used graphic card. There are also derivatives which usually only appear when saving graphics and which take 4 Bit pixel pairs which then will be represented by a single byte. This is only possible, when only up to 16 Colours (4 Bit) are represented by a single chunky byte so that the free space may be used for simple compression. "TrueColour" Quite often 16 and 24 Bit TrueColour graphics may be wrongly called "ChunkyPixel" which is not actually correct. Although "chunky" is not wrong, "chunky pixel" is reserved for palette based data. Using the standard graphic mode with PMPro =========================================== Displaying graphics from outside and within PMPro is managed by SuperView-Library. When speaking of SuperView from now on, this will mean the Library in conjunction with PMPro. In general, SuperView knows planar (BITPLANE) as Chunky- and TrueColour (both ONEPLANE) graphics. It has to be mentioned that only the most common derivatives are supported to not overload the applications with a whole bunch of variations. So without confusing the user other formats will automatically be converted internally to the required format just before the graphic is ready to be used after the loading has finished. The following table shows the system behind this: up to 256 Colours (planar) BITPLANE up to 256 Colours (chunky) ONEPLANE 8 Bit (Palette) more than 256 Colours (TrueColour) ONEPLANE 24 Bit (RGB-Values) Which format that is used internally for representation mainly depends on how the data has been stored within the source graphic file format so that the least amount of conversion overhead will be needed. Why this is so will become clear when coming to the displaying of graphics. Depending on the output medium, either chunky or planar data will be faster. It really does not matter whether this conversion will be or has been done before or during the display operation. When using chunky in general, this might mean multiple conversion (planar ILBM file -> ONEPLANE -> displaying on AGA as bitplane), as well as using bitplanes in general (e.g. converting 24 bitplanes to RGB TrueColour values). So it makes more sense to use the format which comes nearest to the original data (minimal conversion amount) and which only converts when the data actually has to be processed for displaying in another format. With SuperView-Library and many other graphic programs this "dualism" of bitmap and chunky graphics is the reason for long display times of planar graphics on chunky displays and vice versa. Therefore, this means for example that IFF-ILBM is displayed faster on AGA than e.g. BMP but that a graphic card perhaps will display BMP quicker on the screen than IFF-ILBM. When using the SuperView-Library system the user in general does not have to concern themselves since this work will automatically be managed by the specific application of superview-internal display- drivers (SVDrivers). However, it may be useful to know which format would be the fastest one for their own system configuration. In the end it makes sense to save newly created graphics for your own usage only in either Bitplane OR Chunky formats. This does mainly concern 8 Bit graphics (256 colours with palette), since 24 Bit does not allow such assumptions: 24 Bit RGB data in chunky representation will always be used no matter how these have been stored within the source file. There are really strange ways to save 24 Bit graphics but only this one has actually become a standard even if the single vendors of display engines and graphic cards seem to have different opinions about representing these internally as either BGR or RGB values... SVDrivers - display drivers of PMPro ==================================== The following display drivers are currently available for the PMPro: Display/card SVDriver Requirements Shows: ECS ECS ECS*, OS V2.04+ (V38) 8/24 Bit AGA AGA AGA*, OS V3.00+ (V39) 8/24 Bit CyberGraphX CyberGraphX CyberGraphX RTG System 8/24 Bit EGS-System EGS7 EGS-Graphic-Libraries V7 8/24 Bit Picasso II Picasso II Picasso II-Card 8/24 Bit OpalVision OPAL OpalVision Card 8/24 Bit RetinaZ2/Z3 Retina Retina ZII/ZIII Card 8/24 Bit Merlin Merlin Merlin Graphics Card 8/24 Bit ECS / AGA --------- Special ECS/AGA optimised SVDrivers which nevertheless will also work - when driven in RTG mode - in up to 256 Colours with graphic cards (* no AGA chipset needed). The following settings are possible/necessary for configuration: ECS/AGA - 24BITOPERATOR= ; (case-sensitive, ".svoperator" may be added) ; e.g. "24BITOPERATOR=24BitToHAM.svoperator" ; or "24BITOPERATOR=ExtractGrayScales" ; specifies which operation should be performed ; on 24 Bit graphics _before_ displaying them ; (if not specified, "best guess" colours will ; be used, which is really slow) - BITMAPCOPY= ; "BITMAPCOPY=RTG" prevents AGA.svdriver from ; directly copying into Bitmaps which will ; result in a usage of more memory but keeps it ; working. ; Default is "BITMAPCOPY=DIRECT". - SCREENINFRONT ; Put Screen to front _before_ the graphic ; has been displayed (useful with GfxCards) ECS only - 8BITOPERATOR= ; (case-sensitive, ".svoperator" may be added) ; e.g. "8BITOPERATOR=ExtractGrayScales" ; specifies which operation should be performed ; on non-ECS graphics (more than 16 Colours in ; HighRes, more than 32 Colours in LowRes, HAM8) ; (if not specified, will be used to display) CyberGraphX ------------- This driver displays any 1-8 or 24 Bit graphics on the CyberGraphX RTG-System. More than 256 colours will either be displayed in 16 or 24 Bit, depending on preferences and/or free memory. HAM6/8-data will be converted to 24 Bit. Only CyberGraphX screen modes will be used. The following settings are possible/necessary for configuration: - EMUSCREENDEPTH=<16|24> ; beginning depth for opening CyberGraphX Screens ; Default is 16 Bit (which will also be tried ; if opening a 24 Bit Screen fails) ; This does not concern colour depths < 16 Bit, ; except HAM6/8. - SMALLSCREENS ; unless this KeyWord is specified it is not ; possible to open screens smaller than 320x240 EGS7 ---- This driver displays any 1-8 or 24 Bit graphic on the EGS Workbench emulation system. Any data will be displayed in 24 Bit. HAM6/8 data will be converted to 24 Bit. There are no further settings possible/necessary. Picasso II --------- This driver displays any 1-8 or 24 Bit graphic on the Picasso Workbench emulation system (not tested with the cloned vilintuisup.library of CyberGraphX - so the CyberGraphX driver should be used). More than 256 colours will either be displayed in 16 or 24 Bit - depending on preferences and/or free memory. HAM6/8-data will be converted to 24 Bit. Only Picasso screen modes will be used. The following settings are possible/necessary for configuration: - SMALLSCREENS ; unless this KeyWord is specified, it is not ; possible to open screens smaller than 320x240 - EMUSCREENDEPTH=<16|24> ; beginning depth for opening Picasso Screens ; Default is 24 Bit (if opening fails, it will ; try to open a 16 Bit Screen) - AUTOSCROLLADJUST ; this keyword will force Autoscroll whenever ; it would make sense, but the Picasso Software ; would not manage it by itself (when either ; only width or height need to be autoscrolled) OPAL ---- This driver allows the display of graphics on the Framebuffer-/video card OpalVision, which allows a max. 768x512 at 15KHz. The driver is included with kind permission of Steve Quartly. We cannot therefore guarantee full functionality. Retina ------ This driver displays any 1-8 or 24 Bit graphic on the Retina Workbench emulation system. More than 256 colours will either be displayed in 16 or 24 Bit, depending on preferences and/or free memory. HAM6/8-data will be converted to 24 Bit. The following settings are possible/necessary for configuration: - EMUSCREENDEPTH=<16|24> ; beginning depth for opening Retina Screens ; Default is 24 Bit (if opening fails, it will ; try to open a 16 Bit Screen) Merlin ------ This driver displays any 1-8 or 24 Bit graphic on the Merlin Workbench emulation system. More than 256 colours will either be displayed in 16 or 24 Bit, depending on preferences and/or free memory. HAM6/8-data will be converted to 24 Bit. The driver is included with kind permission of Thomas Eigentler. We cannot therefore guarantee full functionality. There are no further settings possible/necessary.