morgan@cory.Berkeley.EDU (Alan Morgan) (12/10/90)
I have been reading comp.sys.amiga on the various 24 bit graphics cards available for the Amiga and I notice that some people have been saying "xyz doesn't give 24 bit output, it just stores colors and manipulates them with 24 bits internally". Is there anything for the Amiga that outputs 24bit color to the screen thus giving 16.4 million colors on screen at once, or do I just misunderstand what I read (not an uncommon occurance :-) ). Thank you for your support. Alan "Blackadder" Morgan morgan@cory
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (12/10/90)
morgan@cory.Berkeley.EDU (Alan Morgan) writes: > I have been reading comp.sys.amiga on the various 24 bit graphics > cards available for the Amiga and I notice that some people have been > saying "xyz doesn't give 24 bit output, it just stores colors and > manipulates them with 24 bits internally". Actually, the complaints (at least from me) are the other direction: systems that _output_ 24-bit color, but don't have enough real memory for pixels to _store_ 24-bit color. > Is there anything for the Amiga that outputs 24bit color to the screen > thus giving 16.4 million colors on screen at once, or do I just > misunderstand what I read (not an uncommon occurance :-) ). Well, you misunderstood, or didn't follow that thought to it's conclusion; no Amiga display has 16.4 million _pixels_, so no Amiga (monitor) display can now put that many colors on the screen at once. What is of interest is whether the display hardware and software support _independent_ assignment of color from a 24-bit palette to _each_ pixel on the screen, without pixel to pixel limitations. Take one readily available example, the HAM-E board. It gains eight bits to work with by going to Amiga low res mode, and using two, horizontally successive four bit deep pixels to encode one eight bit value. It has two modes. The first mode is like a VGA with rotten resolution: it uses the eight bits to access 256, 24 bit wide color look up table slots, and so it can display on one screen a maximum of 256 colors at once, but these can be chosen from the 16.4 million color 24-bit palette. The resolution is 320 dots wide in normal Amiga low res mode, and 368 dots wide in Amiga overscan mode. Vertical resolution is one among 200, 240, 400, or 480 depending on interlace or not and overscan or not. PAL is bigger vertically. This mode has only 256 colors, but they may be _independently_ assigned. The second mode is like HAM, but extended from six to eight bits; two of the eight bits are mode bits, and six of the eight bits are used 1) to pick a new base color for this screen dot, or 2) to modify the previous dot by assigning a new RED, or else a new GREEN, or else a new BLUE color component. The problem is the one that gives fringes in regular HAM mode, the colors are not _not_ _independently_ assigned. Colors next to one another in modify mode always have two of R, G, or B the same. If more than one changes, and you've already run out of base color table entries, then you get a fringe. So, lots of base color table entries are a Good Thing. The six bits for a new base color would normally give you 64 base color table indices, 0 - 63 but they give four away (60, 61, 62, 63) to be color _table_ names instead of color _indices_, which lets you swap among four tables, so you can trade one pixel horizontal constant color for a table swap command, and get four, 60 color tables for a total of 240 table indicies and 24-bit entries (I'm sure those are 240 of the same 256 color look up tables for the first mode). Still, you are left with a lot fewer base colors than screen pixels, so most of the time you're going to be taking a color step along just one of the R, G, or B axes, and so in theory you have a lot less horizontal color space resolution than even the 368 pixels implied by the number of screen dots and four bit data pairs present, and should see a lot of fringing. Really intelligent software, like the second DigiView release, could remove almost all the fringes with vanilla HAM, so for normal scenery, as opposed to test pattern, pictures, HAM-E probably gives excellent visual results, and it does increase the palette from which colors are chosen from HAM's 12 bits and 4096 color choices (fewer than screen pixels), to HAM-E's 24 bits and 16.4 million color choices (more than screen pixels). On the other hand, for pictures with a lot of horizontal color signal information, such as busy fractal landscapes, 24-bits of stored information per displayed pixel is the only way to avoid color fringing or other artifacts, and HAM-E doesn't provide this. True 24-bit frame buffers are more expensive (for the memory alone, to start with), and they do. So, you'll probably get excellent Playmate and other scanned and intellgently converted (by vendor software) to HAM-E displays with HAM-E, and be a bit disappointed at what you can draw to it from C or BASIC or whatever. Doing the base color assignments well for this kind of a system is still a lively research topic, and the best software is proprietary and the algorithms secret. > Thank you for your support. We try. > Alan "Blackadder" Morgan morgan@cory Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
mark@calvin..westford.ccur.com (Mark Thompson) (12/12/90)
In article <9613@pasteur.Berkeley.EDU> morgan@cory.Berkeley.EDU (Alan Morgan) writes: >I have been reading comp.sys.amiga on the various 24 bit graphics >cards available for the Amiga and I notice that some people have >been saying "xyz doesn't give 24 bit output, it just stores colors >and manipulates them with 24 bits internally". Is there anything >for the Amiga that outputs 24bit color to the screen thus giving >16.4 million colors on screen at once, or do I just misunderstand >what I read (not an uncommon occurance :-) ). OK, here is the bottom line on 24 bit frame buffers: Firecracker: 24 bit frame buffer with 24 bit output in RGB Toaster: 24 bit frame buffer with 24 bit output in NTSC composite Color Burst: 24 bit frame buffer with 24 bit output in RGB MediaMaster32(?): 24 bit frame buffer with 24 bit output in NTSC (RGB?) HAM-E and DCTV are not 24 bit frame buffers. RGB outputs will always give you better color than NTSC, HOWEVER, this does NOT mean a board with NTSC outpt is not 24 bit output. It merely means that you cannot truely see the full color fidelity that RGB gives you. Therefore, the Firecracker will give you a better picture than the Toaster, but the Toaster still has 24 bit output (NTSC just can't reproduce it). Each of the above products has its own application. Firecracker & ColorBurst: High quality true color COMPUTER graphics Toaster & MediaMaster32: True color broadcast VIDEO graphics HAM-E & DCTV: Low resolution near true color allowing animation! Note that both the ColorBurst and MediaMaster32 are still both vapor. Hope this clears things up. +--------------------------------------------------------------------------+ | Mark Thompson | | mark@westford.ccur.com | | ...!{decvax,uunet}!masscomp!mark Designing high performance graphics | | (508)392-2480 engines today for a better tomorrow. | +------------------------------------------------------------------------- +