pawn@wpi.wpi.edu (Kevin Goroway) (02/16/89)
Does anyone know what the fastest way to put graphics on the screen is? I have a View/ViewPort/RastPort (no intuition stuff as far as screens/windows) and I want to put graphics on it quickly. I tried DrawImage, which is an Intuition Function, and that bombed, even though I had the Image structure set up correctly, but I guess that's to be expected. I would Use ClipBlit but that coppies from one bitmap to another, which is no help if I can't get the graphic onto a bitmap in the first place! As of now the image is stored as an intuition Image, should I change the format? How would I go about writing it directly into the bitmap? Should the DrawImage function work even though I'm not using intuition, but have a RastPort? Thanks in advance!
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/17/89)
In article <841@wpi.wpi.edu> pawn@wpi.wpi.edu (Kevin Goroway) writes: > Does anyone know what the fastest way to put graphics on the screen is? > I have a View/ViewPort/RastPort (no intuition stuff as far as screens/windows) > and I want to put graphics on it quickly. I tried DrawImage, which is an > Intuition Function, and that bombed, even though I had the Image structure > set up correctly, but I guess that's to be expected. I've used DrawImage successfully on Windows, Screens, and little tiny RastPorts I create to build image type gadgets. From a first reading I would guess you may have done one or both of two things. 1) The RastPort you have isn't initialized properly, I'm not sure if you can initialize the bitmap pointer first and then call InitRastPort() or not, but for luck I always plug in the bitmap pointer after that step. 2) You don't have intuition.library open and thus don't have IntuitionBase pointing at a valid library. Even if you don't "use" Intuition (although technically you are if you call DrawImage()) it costs _nothing_ to open it in C programs. Your program neither increases in size nor slows in execution. It's "free". A side comment about DrawImage(), I use it in my Life program to draw the Cells (mostly because they look like small spheres rather than bits on a screen) And the neat thing about DrawImage() is that you can change a couple of bits in the PlanePick/PlaneOnOff fields and change the colors of your image while sharing the same image data. But that Plane stuff costs, specifially if you don't have the same number of image planes in your Image that you have in your rastport. This is because DrawImage() seems to allocate them for you on the fly so that it can use ClipBlit() or something similar to copy them into your rastport. Anyway, my solution was to preallocate those planes so that DrawImage wouldn't have to. > I would Use ClipBlit but that coppies from one bitmap to another, > which is no help if I can't get the graphic onto a bitmap in the first > place! As of now the image is stored as an intuition Image, should I > change the format? How would I go about writing it directly into the > bitmap? Should the DrawImage function work even though I'm not using > intuition, but have a RastPort? Well, all of the graphics functions will work assuming you have the graphics.library open. These include such things as Draw, Move, Flood, AreaXXX, etc. All you need do is give them a pointer to a RastPort to talk to. Assuming you have the image data already (as your first comment seems to indicate), a really workable solution is to build a BitMap structure that points at it, and then use BltBitMapRastPort() to blit it onto your view/viewport. BBMRP() is documented in the 1.2 autodocs and the Enhancer manual I believe. Soon to be in the new version of the A&W Rom Kernel manuals. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/17/89)
I forgot to mention how you would make the bitmap structure with
preinitialized data, I do it like this :
/* Data definitions for a "gunsight" type graphic */
struct BitMap bm;
/*
* This must be in CHIP memory, if you don't have the chip
* keyword then compile it separately with a switch to force it
* there.
*/
chip UWORD ImageStuff[15] = {
0xf01e, /* XXXX XXXX */
0x8002, /* X X */
0x8002, /* X X */
0x8002, /* X X */
0x0100, /* X */
0x0100, /* X */
0x0100, /* X */
0x0fe0, /* XXXXXXX */
0x0100, /* X */
0x0100, /* X */
0x0100, /* X */
0x8002, /* X X */
0x8002, /* X X */
0x8002, /* X X */
0xf01e /* XXXX XXXX */
};
/* meanwhile in the code somewhere */
InitBitMap(&bm, 15, 15, N);
/* N is the depth of your RastPort */
bm.Planes[0] = (PLANEPTR) ImageStuff;
for (i = 1; i < N; i++) {
bm.Planes[i] = (PLANEPTR) AllocRaster(15,15);
if (!(bm.Planes[i]))
ProcessError(NOMEMORY);
}
/* ... Later that same day ... */
/* BltBitMapRastPort
(srcbm,srcx,srcy,destrp,destX,destY,sizeX,sizeY,minterm);
set the minterm to reflect the draw mode
*/
MINTERM = MyRPort->minterms[0]; /* Use the rastports current mode */
BltBitMapRastPort(&bm, 0, 0, MyRPort, X, Y, 15, 15, MINTERM);
..etc remember to free up the image planes allocated above before
exiting.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.