smargari@nmsu.edu (Susan Margarit) (04/09/91)
I am using color offscreen bitmaps for the first time and, of course, I am having problems. I am writing a card game, actually, updating one I wrote to color now that I have a color system. I have a 256 color picture as a backdrop stored in one offscreen bitmap. I use a second offscreen bitmap to redraw the hand after each card play. I blast the background to the hand bitmap and then draw the cards over that and then blast the whole thing on to the screen so that the player doesnt have to watch the cards blank and redraw. Sometimes I draw the cards directly on the screen in color. The problem is that the cards drawn directly to the screen come out perfectly in color but the hand that comes from the offscreen map come out in monochrome on a color background. The color backdrop stays in color in the transfer from its offscreen map to the hand offscreen map to the screen but the cards are mono. All of the offscreen maps are created with the same routine ( taken from MacTutor/TN #120). The only difference between drawing the cards to the screen and the offscreen bitmap is a SetPort call ( ie SetPort(handPort) or SetPort(OnscreenPort)). Any Ideas?? Question #2. Why is it that when you draw a 256 color pict resource into a color window, the DrawPicture routine ignores the color palette in the pict and uses the default palette? When you paste it into the scrapbook, the scrapbook uses the correct palette. How do you get DrawPicture to use the correct palette? Thanks for your suggestions! Jim Margarit --No Sig Required--
fry@zariski.harvard.edu (David Fry) (04/09/91)
It's pretty simple to parse the PICT opcodes to get the color table for any PixMaps. Just as simple and more compatible is to use QuickDraw bottleneck routines to get the color table from PixMaps. Quite a number of programs do this, I think. PixMap color tables are what people most often want, I think, but the bottleneck approach also allows you to keep track of all the colors used for Lines, Polys, etc. This is much harder, but there's some sample code from Apple on how to do this, although it's still an incomplete attempt. Starting with System 7.0, though, there are Picture Utility functions which will return all this information for you with one toolbox call. Fun times ahead! David Fry fry@math.harvard.EDU Department of Mathematics fry@huma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
hpoppe@ncar.ucar.edu (Herb Poppe) (04/09/91)
In article <SMARGARI.91Apr8222848@emmy.nmsu.edu> smargari@nmsu.edu (Susan Margarit [or is it Jim - or a "Man Called Sue"]) writes: > Question #2. Why is it that when you draw a 256 color pict > resource into a color window, the DrawPicture routine ignores > the color palette in the pict and uses the default palette? There is no color palette in a PICT. > When you paste it into the scrapbook, the scrapbook uses the correct palette. Sorry, it doesn't. The Scrapbook is a DA. I would be surprised if it used the Palette Manager at all. I suspect that (with SingleFinder) the palette that is used is whatever is being used (or not used) by the program it is executing in. In MultiFinder, it runs inside DA Handler. I would be surprised if DA Handler uses the Palette Manager; after all, the Finder doesn't (in System 6.0.x and earlier). > How do you get DrawPicture to use the correct palette? You have to set up the correct palette yourself before you call DrawPicture. You could paste the palette into the Clipboard along with the PICT if you wrote the "pasting" program. But that is probably a no-no. Quoting from Inside Mac Vol. 1-454: "From the user's point of view there can only be one thing in the Clipboard at a time, but the application may store more than one version of the information in the scrap, each representing the same Clipboard contents in a different form." A 'PICT' and a 'pltt' are not different forms of the same "thing". You could ignore this quote; but, if you didn't write the "pasting" program, chances are "they" didn't include a "pltt" anyway. So you are left with reading through all the PICT opcodes, extracting all the color references and building the "correct" palette. Good luck, and when you've accomplished that please post your efforts to the net. Instant fame and fortune will be yours (well, fame, at least). Apple, however, will not be pleased. Quoting from Inside Mac Vol. 5-96: "The opcode information in Table 3 is provided for the purpose of debugging application-generated PICT files. Your application should generate and read PICT files only by using standard QuickDraw or Color QuickDraw routines (OpenPicture, ClosePicture)." None of these routines, however, do what needs to be done. In short, there doesn't appear to be a legal way to do this, which might explain while one can never successfully copy/paste a color PICT between any two given programs and get the colors one expects. By the way, I would love to be proven wrong. Herb Poppe hpoppe@ncar.ucar.edu NCAR (303) 497-1296 1850 Table Mesa Dr. Boulder, CO 80307-3000
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (04/10/91)
In article <10972@ncar.ucar.edu> hpoppe@ncar.ucar.edu (Herb Poppe) writes: >In article <SMARGARI.91Apr8222848@emmy.nmsu.edu> smargari@nmsu.edu (Susan >Margarit [or is it Jim - or a "Man Called Sue"]) writes: >> Question #2. Why is it that when you draw a 256 color pict >> resource into a color window, the DrawPicture routine ignores >> the color palette in the pict and uses the default palette? >There is no color palette in a PICT. Depends. There is no color palette opcode in the PICT definition, but the opcodes for PixMaps have an entry for a CLUT. Those could be used by either parsing the opcodes or patching the QDProcs. If the QDProcs are patched, you should do two passes: one with all procs except copybits set to do nothing, and copybits set to a routine that grabs and saves the CLUT of the PixMap, and the other with normal QDProcs, after setting the color table to the one extracted. This is because the PICT could contain drawing in color with primitives (lines and stuff) before the pixmap is reached, and changing the CLUT when reaching the pixmap would muck up the colors of the primitives drawn earlier. Parsing the opcodes is more straightforward, but writing a parsing routine involves a large amount of data (since each opcode may have different amount of data attached to it). Either way, however, you will have to deal with the (admittedly unlikely, but still possible) case that there is more than one pixmap in the PICT definition, each with a different CLUT. In this case the best way is probably to allocate an offscreen 24-bit or 16-bit deep pixmap, drawpicture into it, and then copybits onto the screen with the system clut active and in ditherCopy mode. >> When you paste it into the scrapbook, the scrapbook uses the correct >palette. >Sorry, it doesn't. I don't remember myself, but I believe you're right, the Scrapbook doesn't. >The Scrapbook is a DA. I would be surprised if it used the Palette Manager >at all. I suspect that (with SingleFinder) the palette that is used is >whatever is being used (or not used) by the program it is executing in. In >MultiFinder, it runs inside DA Handler. I would be surprised if DA Handler >uses the Palette Manager; after all, the Finder doesn't (in System 6.0.x >and earlier). There seems to be a misunderstanding here. There are palettes ('pltt's), which are managed by the Palette Manager, and there are color lookup tables ('clut's) managed by ColorQD/GDevice Mgr/Color Mgr/Palette Mgr. The screen display is determined by the current clut, which you can set through the device manager (by mucking with the color table attached to the graphic device's pixel map, I believe - I also believe this is not recommended for human interface reasons and possibly others, but I might be wrong). Additio- nally, color windows have palettes attached to them, which automatically kick in when they are activated (the system calls ActivatePalette). You can convert from a clut to a palette and back with a couple of Palette Manager routines whose name I forget. >> How do you get DrawPicture to use the correct palette? >(stuff deleted) >So you are left with reading through all the PICT opcodes, extracting all >the color references and building the "correct" palette. Good luck, and >when you've accomplished that please post your efforts to the net. Instant >fame and fortune will be yours (well, fame, at least). Apple, however, >will not be pleased. Quoting from Inside Mac Vol. 5-96: "The opcode >information in Table 3 is provided for the purpose of debugging >application-generated PICT files. Your application should generate and >read PICT files only by using standard QuickDraw or Color QuickDraw >routines (OpenPicture, ClosePicture)." None of these routines, however, do >what needs to be done. IM might say that, but parsing the PICT structure has long been an accepted way of extracting data from a PICT. I believe IM also says somewhere that you might want to parse a PICT in order to disassemble it and extracting a pixmap for private storage or somesuch, thereby implying that there are legit reasons for parsing PICTs. Besides, a) a bunch of real world apps do it (to extract EPSF in PicComments for example), and b) it's not absolutely necessary to parse the actual PICT data, as mentioned above: you can just patch the QDProcs (which is extremely legal). >In short, there doesn't appear to be a legal way to do this, which might >explain while one can never successfully copy/paste a color PICT between >any two given programs and get the colors one expects. Um, depends on the program. Director comes to mind when I try to paste a picture with a custom CLUT and it gives you an option to import the CLUT as well. Photoshop certainly can, as do other graphics programs. They may offer to change the palette, change the palette without asking, perform diffusion (using ditherCopy mode in CopyBits, etc). It can be done, it's just a hassle. The point is, if you *really* want to change the palette, you can. -Ivan Cavero Belaunde Visualist Digital Video Applications Corp. (DiVA) Internet: captkidd@ATHENA.MIT.EDU
jmatthews@desire.wright.edu (04/10/91)
In article <SMARGARI.91Apr8222848@emmy.nmsu.edu>, smargari@nmsu.edu (Susan Margarit) writes: > I am using color offscreen bitmaps for the first time and, of course, > I am having problems. > [...] > The only difference between drawing the cards to the screen and the > offscreen bitmap is a SetPort call ( ie SetPort(handPort) or > SetPort(OnscreenPort)). Any Ideas?? > [...] > Jim Margarit Would it help any to use GetGWorld/SetGWorld (instead of GetPort/SetPort)? This worked when I was animating a 256 gray scale PICT. John o----------------------------------------------------------------------------o | John B. Matthews, jmatthews@desire.wright.edu, am103@cleveland.freenet.edu | | "Say...what's a mountain goat doing way up here in a cloud bank?" - Larson | o----------------------------------------------------------------------------o
smargari@nmsu.edu (Susan Margarit) (04/11/91)
Actually, I managed to get the right palette by extracting the color table from the GIF that I had pasted from Giffer to the scrapbook. And the only reason the scrapbook had the right palette was because it had just been set by Giffer before I pasted it in. When I went back to verify what you said, there was my picture looking like a scene from a bad seventies sci fi flick. Other replies gave the same hack as you for getting the color out of a PICT. Just imagine if Kodak had the same attitude about color film. 'Yeah, you can take color pictures with our film but we cannot guarantee that the colors will be those in the original. Sure we know the right colors, but that's proprietary information! Thanks for the reply... Jim (aka the better connected half, Sue) Margarit
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (04/13/91)
In article <SMARGARI.91Apr8222848@emmy.nmsu.edu> smargari@nmsu.edu (Susan Margarit) writes: >I am using color offscreen bitmaps for the first time and, of course, >I am having problems. I am writing a card game, actually, updating >one I wrote to color now that I have a color system. I have a >256 color picture as a backdrop stored in one offscreen bitmap. I use >a second offscreen bitmap to redraw the hand after each card play. >I blast the background to the hand bitmap and then draw the cards >over that and then blast the whole thing on to the screen so that >the player doesnt have to watch the cards blank and redraw. Sometimes >I draw the cards directly on the screen in color. The problem is >that the cards drawn directly to the screen come out perfectly in >color but the hand that comes from the offscreen map come out in >monochrome on a color background. The color backdrop stays in color >in the transfer from its offscreen map to the hand offscreen map to >the screen but the cards are mono. All of the offscreen maps are >created with the same routine ( taken from MacTutor/TN #120). The >only difference between drawing the cards to the screen and the >offscreen bitmap is a SetPort call ( ie SetPort(handPort) or >SetPort(OnscreenPort)). Any Ideas?? I should have thought of this before, but it just came to me. One possible reason is that the gdevice for the handPort is not properly set up. What could happen there is that when you do CopyBits, and both source and destination have the same clut, it don't think it requires an inverse table from the GDevice. So if the backdrop and the handPort have the same clut, the CopyBits would work fine. If the cards have a different clut than the handPort, however, CopyBits would need an inverse table installed in the gDevice that is attached to the handPort. I'd check the code that sets up the graphics device when creating the grafport. It really does sound like an inverse table problem, tho'. Hope this helps, -Ivan Cavero Belaunde Visualist Digital Video Applications Corp. (DiVA) Internet: captkidd@ATHENA.MIT.EDU