...|murtoa.oz|munnari.oz|charlie.oz|sang. (Shane Hyde) (08/10/89)
I was wondering if there was anyone out there, who could tell me how to program copper effects in C on Amy. The ones I am specifically trying to do are color changes midway down the screen. I don't have any docs on the register assignments. So can someone please tell me what the hell I do with the UCopLst, CopLst, CWait, CMove and other such esoteric functions described very badly in the book I have. I hope someone knows... sang@charlie.cc.deakin.oz Deakin Uni. Victoria Aust...
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/11/89)
In article <7741@charlie.OZ> (Shane Hyde) writes: > I was wondering if there was anyone out there, who could tell me >how to program copper effects in C on Amy. The ones I am specifically >trying to do are color changes midway down the screen. I don't have any >docs on the register assignments. There are a couple of ways to do this, one is to much with UCopList et al and the other is to simply set up two viewports with different colors. Have the second one start where you want the colors to change. Then you can MrgCop()/LoadView() and poof. I wrote a little program that did it this way for the Dr. Dobbs article, 'cuz it's short I've included it below. /* * dualvp.c - Dual Viewports on the amiga * Written 4/4/89 by C. McManis using Lattice C 5.02 */ #include <exec/types.h> #include <exec/memory.h> #include <graphics/gfx.h> #include <graphics/view.h> #include <graphics/gfxbase.h> #include <graphics/rastport.h> extern struct GfxBase *GfxBase; char *TextString = "Amiga Graphics Example"; /* Viewport 0 colors */ UWORD colors0[4] = {0xccc, 0x000, 0x0f0, 0x00f}, /* Viewport 1 colors */ colors1[4] = {0x0f0, 0xc0c, 0xf00, 0xfff}; void _main() { struct View MyView, *OldView; struct ViewPort Vp0, Vp1; struct BitMap Bits; struct RasInfo MyRaster; struct RastPort rp; int i; /* Open the resident graphics library */ GfxBase = (struct GfxBase *)OpenLibrary("graphics.library",0L); if (!GfxBase) exit(1); OldView = GfxBase->ActiView; /* Save this away */ /* Initialize the View structures */ InitView(&MyView); InitVPort(&Vp0); InitVPort(&Vp1); Vp1.Next = NULL; Vp0.Next = &Vp1; /* create a linked list of viewports */ MyView.ViewPort = &Vp0; /* With the first one being Vp0 */ /* Set up some display memory */ InitBitMap(&Bits, 2, 640, 200); Bits.Planes[0] = (PLANEPTR) AllocMem(2*RASSIZE(640, 200),MEMF_CHIP+MEMF_CLEAR); Bits.Planes[1] = Bits.Planes[0] + RASSIZE(640, 200); if (!Bits.Planes[0]) goto cleanup; MyRaster.BitMap = &Bits; MyRaster.RxOffset = 0; MyRaster.RyOffset = 0; MyRaster.Next = NULL; /* Both viewports are looking at the same display memory but have * different sets of colors */ Vp0.RasInfo = &MyRaster; Vp0.DWidth = 320; Vp0.DHeight = 175; Vp0.ColorMap = (struct ColorMap *)GetColorMap(4); LoadRGB4(&Vp0, colors0, 4); Vp1.RasInfo = &MyRaster; Vp1.DWidth = 640; Vp1.DHeight = 20; Vp1.DyOffset = 179; Vp1.Modes = HIRES; Vp1.ColorMap = (struct ColorMap *)GetColorMap(4); LoadRGB4(&Vp1, colors1, 4); /* Initialize a RastPort so that we can draw into that memory. */ InitRastPort(&rp); rp.BitMap = &Bits; SetAPen(&rp, 1); /* Foreground color */ SetBPen(&rp, 0); /* Background color */ Move(&rp, 3, 12); /* Move the graphics cursor to (3, 12) */ /* Write something */ Text(&rp, TextString, strlen(TextString)); MakeVPort(&MyView, &Vp0); /* Build the copper list for Viewport 0 */ MakeVPort(&MyView, &Vp1); /* Build the copper list for Viewport 1 */ MrgCop(&MyView); /* Merge it into the final list */ LoadView(&MyView); /* Show it off */ /* SPIN FOR A WHILE */ for (i=0; i<1000000; i++) ; LoadView(OldView); /* Return to the old view */ cleanup: /* Now give back the memory other tasks may need it */ if (!Vp0.ColorMap) FreeColorMap(Vp0.ColorMap); if (!Vp1.ColorMap) FreeColorMap(Vp1.ColorMap); FreeVPortCopLists(&Vp0); FreeVPortCopLists(&Vp1); FreeCprList(MyView.LOFCprList); if (!Bits.Planes[0]) FreeMem(Bits.Planes[0], 2*RASSIZE(640, 200)); if (!GfxBase) CloseLibrary(GfxBase); exit(0); } --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. "A most excellent barbarian ... Genghis Kahn!"
451061@UOTTAWA.BITNET (Valentin Pepelea) (08/11/89)
Chuck McManis <cmcmanis%pepper@sun.com> writes in <120748@sun.Eng.Sun.COM> > /* SPIN FOR A WHILE */ > for (i=0; i<1000000; i++) > ; Tss, tss, tss. Have we forgotten about Delay()? You realize, if I were German and had just swallowed too much beer, I would have flamed you for this? :-) Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA
shadow@pawl.rpi.edu (Deven T. Corzine) (08/11/89)
Chuck McManis <cmcmanis%pepper@sun.com> writes in <120748@sun.Eng.Sun.COM> cmcmanis> /* SPIN FOR A WHILE */ cmcmanis> for (i=0; i<1000000; i++) cmcmanis> ; On 10 Aug 89 22:40:16 GMT, 451061@UOTTAWA.BITNET (Valentin Pepelea) said: Valentin> Tss, tss, tss. Have we forgotten about Delay()? Ugly thing about Delay() is that it's part of dos.library... Valentin> You realize, if I were German and had just swallowed too Valentin> much beer, I would have flamed you for this? :-) Well, now. From what appears to be the norm among German Amiga programmers, I would expect approval for the busy wait, and disapproval for otherwise cooperating with the operating system... [You shouldn't need to ask for *permission* to go play with the hardware directly! You know the registers' addresses...] Deven p.s. :-) -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
balzer@frambo.enet.dec.com (Christian Balzer) (08/14/89)
In article <SHADOW.89Aug11080523@pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes... > >On 10 Aug 89 22:40:16 GMT, >451061@UOTTAWA.BITNET (Valentin Pepelea) said: >Valentin> Tss, tss, tss. Have we forgotten about Delay()? > >Ugly thing about Delay() is that it's part of dos.library... You're absolutly right, Deven. I personally avoid Delay() wherever possible. Anybody remember the Delay(0) bug? ;-) >Valentin> You realize, if I were German and had just swallowed too >Valentin> much beer, I would have flamed you for this? :-) > >Well, now. From what appears to be the norm among German Amiga >programmers, I would expect approval for the busy wait, and >disapproval for otherwise cooperating with the operating system... >[You shouldn't need to ask for *permission* to go play with the >hardware directly! You know the registers' addresses...] Sigh, another stereotype. And what's really sad about it, is the fact that it's true. :-( :-} My personal estimate is that still about 50% of the German (European, Terrestrian?) Amiga programmers prefer dirty tricks over compliance to well defined guidelines. Or they just don't read the manuals. This percentage seems to rise dramatically for game programmers. But they all follow a long and truly American tradition, ;-) with Electronic Arts taking the lead. But here's something that really boggled my mind: The recent issue of the German Amiga magazine featured an interview with Mr. AmigaArt himself, Jim Sachs. Within this interesting interview, Mr. Sachs states that he "takes over the up to it's last byte" and never uses OS routines or relocateable code. Thus his programs will never multitask, but since he needs every bit of CHIPmem, this wouldn't work in the first place and slow down his games too much. While I can understand _some_ of practices above and would tolerate them if they would result in a killer game, Mr. Sachs had one more "hint" for the anxious German public. He said he prefers assembler to C, since it allows such nice things as self-modifying code!!! Whoa, I can see the next generation of Amiga games coming, all of them crashing on my A2620 system... ;-} (The interview might be a forgery (unlikely) or heavily edited, but this is what the German audience read.) I just wait for the kids coming to me and yelling: "You're no decent Amiga programmer, Jim Sachs told us so. Now let's go and take over some blitter registers." ;-) >p.s. :-) Appreciated, but not really necessary in this contents. As stated above, you're (unfortunately) perfectly right. A fact's a fact. ;-) Regards, - <CB> -- _ _ / / | \ \ <CB> aka Christian Balzer - The Software Brewery - // < < |-< > decwrl!frambo.dec.com!CB | unido!decum!frambo.dnet!CB // \ \_ |_/ / I-Net: CB@frambo.enet.dec.com | E-Net: FRAMBO::BALZER \\ // ------------ PMail: Im Wingertsberg 45, D-6108 Weiterstadt, F.R.G. \X/ "And we will all go down together..." -Billy Joel
tron1@tronsbox.UUCP (K.J.Jamieson) (08/18/89)
>with Mr. AmigaArt himself, Jim Sachs. Within this interesting >interview, Mr. Sachs states that he "takes over the up to it's last >byte" and never uses OS routines or relocateable code. Thus his >programs will never multitask, but since he needs every bit of CHIPmem, In an OLD ( > 1 year) article in Amiga World (?) , Jim also said "why use a blitter , it's so much faster to have the 68000 move things!" Exact quote will be dug up and posted. **************************************************************************** "Lord, you gave us feet to waddle. A tux for tails and bods like bottles.. but 'scuse us if we find no levity, since you also gave us gravity. But to adversity, we say NUTS! And when it's time to fly the coop, we flap and beat to lift our buts, and we're left as walking nincompoops. So Lord, I'd think you more than wise, (and me much less a jerk) if only once you might supply..... SOME PENGUIN WINGS THAT WORK!" Opus '83 - 89 R.I.P. UUCP: tron1@tronsbox.UUCP uunet!mimsy!oddjob!clout!ddsw1!tronsbox!tron1 Sysop, The Penthouse ]I[ BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
shadow@pawl.rpi.edu (Deven T. Corzine) (08/18/89)
Valentin> Tss, tss, tss. Have we forgotten about Delay()? Deven> Ugly thing about Delay() is that it's part of dos.library... Christian> You're absolutly right, Deven. I personally avoid Delay() Christian> wherever possible. Anybody remember the Delay(0) bug? ;-) No, but Delay() should be in exec.library as Sleep(), ideally, calling timer.device transparently... if not, it should be Sleep() in timer.device. It's *not* a DOS function. *sigh* Valentin> You realize, if I were German and had just swallowed too Valentin> much beer, I would have flamed you for this? :-) Deven> Well, now. From what appears to be the norm among German Amiga Deven> programmers, I would expect approval for the busy wait, and Deven> disapproval for otherwise cooperating with the operating Deven> system... [You shouldn't need to ask for *permission* to go Deven> play with the hardware directly! You know the registers' Deven> addresses...] Christian> Sigh, another stereotype. And what's really sad about it, Christian> is the fact that it's true. :-( :-} Stereotypical but true, I'm afraid... Christian> My personal estimate is that still about 50% of the German Christian> (European, Terrestrian?) Amiga programmers prefer dirty Christian> tricks over compliance to well defined guidelines. Or they Christian> just don't read the manuals. This percentage seems to rise Christian> dramatically for game programmers. But they all follow a Christian> long and truly American tradition, ;-) with Electronic Arts Christian> taking the lead. It's a bad attitude. Christian> [...] Mr. Sachs had one more "hint" for the anxious German Christian> public. He said he prefers assembler to C, since it allows Christian> such nice things as self-modifying code!!! I rest my case. Deven> p.s. :-) Christian> Appreciated, but not really necessary in this contents. As Christian> stated above, you're (unfortunately) perfectly right. A Christian> fact's a fact. ;-) Yeah, but some people are easily offended. ;-) Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.