bader+@andrew.cmu.edu (Miles Bader) (08/08/88)
Currently, as I understand it, in instances where you want a background to show through (like with sprites, or in dual-playfield mode), a particular color register indicates "see-through." I think a neat way to do it would to be eliminate the special behavior of that register, and add another 4 bits to ALL the color registers (for a total of 16 bits each), which would be "opaqueness": a value of 0 would mean "completely transparent," and a value of 15 would mean completely opaque. The color of a pixel would be (fg*op)+(bg*(15-op)) for each of red, blue and green, where op is the opaqueness, fg is the intensity of this layer, and bg is the intensity of the underlying layer. -Miles
brant@alberta.UUCP (Brant Coghlan) (08/10/88)
In article <0Wz-V=Au8k-083IFce@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >I think a neat way to do it would to be eliminate the special >behavior of that register, and add another 4 bits to ALL the color >registers (for a total of 16 bits each), which would be "opaqueness": I think Miles has the right idea. Allow windows to be opened with various degrees of opaqueness. The application running underneath would still be visable so the user could be receiving info from both programs. Imagine this : you are displaying a digitized or raytraced picture and you want to look at the CAD description of it, your engineering notes, or a structural analysis of what ever you are displaying, so you open a transparent window on top of the picture. You could see important differences and make changes accordingly. You could open a drawing program in a transparent window and sketch an outline or addition to the original picture, without touching the original. CBM please include such a feature in V1.5 (1.4 would be even better). -Brant -----Opaque Windows: the way of the future------- -- Brant Coghlan (403) 487-3619 ...{ubc-vision,sask,ihnp4}!alberta!brant Dept. of Comp. Science, 615 GSB, U of Alberta, Edmonton, Alberta, Canada
jms@antares.UUCP (joe smith) (08/11/88)
In article <0Wz-V=Au8k-083IFce@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >Currently, as I understand it, in instances where you want a >background to show through (like with sprites, or in dual-playfield >mode), a particular color register indicates "see-through." This is not how it works. The hardware does not pickup a color value, locate the corresponding color register, and then decide to be transparent based on what it in the register. Instead, it picks up the color value and notices that it matches the bit pattern that says to be transparent instead of going to the color registers. >I think a neat way to do it would to be eliminate the special >behavior of that register, and add another 4 bits to ALL the color >registers (for a total of 16 bits each), which would be "opaqueness": Given that a 5-plane screen uses all 32 color registers for the picture, these extra 4 bits would be used only by the sprites. That is, the mouse pointer could be made into a shadow, but could not have a color that is different from the screen. In article <1515@pembina.UUCP> brant@pembina.UUCP (Brant Coghlan) writes: >... you are displaying a digitized or raytraced picture and you want to look >at the CAD description of it, your engineering notes, or a structural analysis >of what ever you are displaying, so you open a transparent window on top of >the picture. You could see important differences and make changes accordingly. This is currently possible using extra-halfbright mode, which produces a transparent shadow on top of a 32-color screen. However, it is not very readable; text on a dark background becomes invisible. I orginally started this follow-up to state that posters were asking for something that could not be done without redesigning the Amiga, but now see some possiblilities. You can't overlay a window on top of a hires screen because all the memory bandwidth is used up fetching 4 bit planes in double time. And raytraced HAM images can't be overlayed because Agnus won't read more than 6 bit planes at a time. However, a combination of dual-playfield and extra-halfbright mode does have possibilities. Instead of just 3+3 lores and 2+2 hires bit planes, allow a 5+1 lores mode. This requires adding a 33rd color register which is selected whenever a bit is on in the 6th bitplane is on, regardless if the other 5 bits. If this color register were set to bright green for instance, then a single bitplane of 40-column text could be overlayed on top of a 32-color screen. And the combination of 4+2 planes would use only 20 of the 32 color registers. Or how about 4+(1+1)? The 4 means 4 bitplanes of lores (320 columns, 16 colors) and (1+1) means 1 bitplane of hires (640 columns, single color) being fetched in double-time. That is, two pixels of overlay for each pixel of background. While we're dreaming, why not 6+(1+1), utilizing all 8 DMA slots. Combine the graphics from 6 lores bitplanes (32 color, EHB, HAM) with one hires bitplane. (Or even triple-play field: 3+3+(1+1)!) Now here's a suggestion that could reasonably make it into 1.4 and work with existing Amigas (including A1000): Convert the Workbench screen to use dual-playfields. Put all transparent windows on the other pair of bitplanes. Add a new gadjet to toggle window's status from being in the opaque bit planes to being in the transparent bit planes. Dragging a transparent window does not affect opaque windows and vice versa. But moving a transparent window from being on top of another transparent window does require a refresh. So, Commodore, does this suggestion have merit? -- +-----------------------------------------------------------------------------+ | TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 | +-----------------------------------------------------------------------------+
paolucci@snll-arpagw.UUCP (Sam Paolucci) (08/12/88)
In article <1515@pembina.UUCP> brant@pembina.UUCP (Brant Coghlan) writes: >I think Miles has the right idea. Allow windows to be opened with various >degrees of opaqueness. The application running underneath would still be >visable so the user could be receiving info from both programs. Imagine this >: you are displaying a digitized or raytraced picture and you want to look >at the CAD description of it, your engineering notes, or a structural analysis >of what ever you are displaying, so you open a transparent window on top of >the picture. You could see important differences and make changes accordingly. >You could open a drawing program in a transparent window and sketch an outline >or addition to the original picture, without touching the original. > > CBM please include such a feature in V1.5 (1.4 would be even better). >-Brant >-----Opaque Windows: the way of the future------- >-- > Brant Coghlan (403) 487-3619 ...{ubc-vision,sask,ihnp4}!alberta!brant > Dept. of Comp. Science, 615 GSB, U of Alberta, Edmonton, Alberta, Canada > Having the capability of opening up transparent windows (and transparent screens) would allow one to write a terminal program that fully emulated some of the Tektronix 4100 and 4200 series terminal which use two screens, one for graphics and one for alphanumeric communication. (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
jdow@gryphon.CTS.COM (J. Dow) (08/12/88)
In article <0Wz-V=Au8k-083IFce@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >Currently, as I understand it, in instances where you want a >background to show through (like with sprites, or in dual-playfield >mode), a particular color register indicates "see-through." > >I think a neat way to do it would to be eliminate the special >behavior of that register, and add another 4 bits to ALL the color >registers (for a total of 16 bits each), which would be "opaqueness": >a value of 0 would mean "completely transparent," and a value of 15 >would mean completely opaque. The color of a pixel would be >(fg*op)+(bg*(15-op)) for each of red, blue and green, where op is the >opaqueness, fg is the intensity of this layer, and bg is the >intensity of the underlying layer. > Um, Miles, wanna tell me what the Amiga is going to use for bus bandwidth to do all this? Hires 4 bitplanes currently burns ALL the CHIP ram bandwidth durning the active portions of the frame. 4 more bitplanes MIGHT be possible if you go to 32 bit buses in the Amiga. I kinda wish they would. We could well use that added bandwidth. (And it'd be fun to listen to the HW vendors scream in anguish over the chaned bus yet again. <snicker> (I'm feeling nasty tonite!) >-Miles -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (08/15/88)
In article <2460@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article ... paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >> Having the capability of opening up transparent windows (and >> transparent screens) would allow one to write a terminal program that >> fully emulated some of the Tektronix 4100 and 4200 series terminal >> which use two screens, one for graphics and one for alphanumeric >> communication. > >Transparent screens are not possible with the current hardware architecture. > >Transparent windows are not necessary for this. Just open up one window in >a DualPlayfield screen, and forge a couple of rastports: one to the top >playfield (1 bit deep) and one to the bottom playfield (3 bits deep). This >gives you 1 color text on top of 8 color graphics. Unfortunately that will not do to get full emulation. Especially for the Tek 4200 series where >8 colors are necessary. -+= SAM =+- (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
peter@sugar.uu.net (Peter da Silva) (08/16/88)
In article ... paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > >Transparent windows are not necessary for this. Just open up one window in > >a DualPlayfield screen, and forge a couple of rastports: one to the top > >playfield (1 bit deep) and one to the bottom playfield (3 bits deep). This > >gives you 1 color text on top of 8 color graphics. > Unfortunately that will not do to get full emulation. Especially for > the Tek 4200 series where >8 colors are necessary. OK, how about 32 colors with Extra-Halfbright text? That's the most I can offer. -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
paolucci@snll-arpagw.UUCP (Sam Paolucci) (08/17/88)
In article <2488@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article ... paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >> >Transparent windows are not necessary for this. Just open up one window in >> >a DualPlayfield screen, and forge a couple of rastports: one to the top >> >playfield (1 bit deep) and one to the bottom playfield (3 bits deep). This >> >gives you 1 color text on top of 8 color graphics. > >> Unfortunately that will not do to get full emulation. Especially for >> the Tek 4200 series where >8 colors are necessary. > >OK, how about 32 colors with Extra-Halfbright text? That's the most I can >offer. How do you get 32 colors with DualPlayfield? Or do I misunderstand you? Please elaborate. (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) (FILLER) -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
peter@sugar.uu.net (Peter da Silva) (08/18/88)
From <212@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci): > How do you get 32 colors with DualPlayfield? Or do I misunderstand you? > Please elaborate. You misunderstand me. This is *instead* of DualPlayfield. You use a 6-bitplane screen, planes 0-4 are 32 colors of TEK graphics. Plane 5 is text. The screen is set up extra-halfbright, so the text appears as a darker shade of the colors. It might be hard to read for certain patterns and color combinations (:->). -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
papa@pollux.usc.edu (Marco Papa) (08/18/88)
In article <2501@sugar.uu.net| peter@sugar.uu.net (Peter da Silva) writes: |From <212@snll-arpagw.UUCP|, paolucci@snll-arpagw.UUCP (Sam Paolucci): || How do you get 32 colors with DualPlayfield? Or do I misunderstand you? || Please elaborate. | |You misunderstand me. This is *instead* of DualPlayfield. You use a 6-bitplane |screen, planes 0-4 are 32 colors of TEK graphics. Plane 5 is text. The screen |is set up extra-halfbright, so the text appears as a darker shade of the |colors. It might be hard to read for certain patterns and color combinations |(:->). Peter, I am sorry but you can have 32-colors (5-bitplanes) or use halfbright mode ONLY in LOW-RESOLUTION screens. The result is a very lousy looking Tek 4105 emulator. Sam's solution (3-bitplanes for graphics, 1 bitplane for text, HIGH-RES), is the best compromise. I can tell because I tried them all and ended up with the above for the Tek 4105 I implemented last year, and that should be included in the Professional version of A-Talk III. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
mp1u+@andrew.cmu.edu (Michael Portuesi) (08/22/88)
> *Excerpts from ext.nn.comp.sys.amiga: 12-Aug-88 Re: graphics chips ideas J.* > *Dow@gryphon.CTS.COM (1722)* > In article <0Wz-V=Au8k-083IFce@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles > Bader) writes: > >Currently, as I understand it, in instances where you want a > >background to show through (like with sprites, or in dual-playfield > >mode), a particular color register indicates "see-through." > > > >I think a neat way to do it would to be eliminate the special > >behavior of that register, and add another 4 bits to ALL the color > >registers (for a total of 16 bits each), which would be "opaqueness": > >a value of 0 would mean "completely transparent," and a value of 15 > >would mean completely opaque. The color of a pixel would be > >(fg*op)+(bg*(15-op)) for each of red, blue and green, where op is the > >opaqueness, fg is the intensity of this layer, and bg is the > >intensity of the underlying layer. > > > Um, Miles, wanna tell me what the Amiga is going to use for bus bandwidth to > do > all this? Hires 4 bitplanes currently burns ALL the CHIP ram bandwidth durning > the active portions of the frame. The enhancements Miles was suggesting have nothing at all to do with increasing the number of bitplanes and hence bus DMA. What he did suggest was adding a few bits of extra attribute to each color register to describe the "opaqueness" of that color on the screen. The amount of bus bandwidth necessary to fetch these extra bits is nominal. The only thing not nominal is the chip space necessary for an extra four bits on every color register plus the additional logic necessary to compute pixel colors based on opaqueness as the raster is being generated. Besides having the only computer system whose interface would support transparent and translucent windows, you could do some *amazing *video effects by having various levels of transparency implemented in hardware. Since the Amiga's future is going to lie in desktop video production, it doesn't seem such a bad idea. You can simulate this right now in software using HAM mode, but it takes lots of CPU cycles to lay down an image properly. --M Michael Portuesi / Information Technology Center / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "if you ain't ill it'll fix your car"