davewt@NCoast.ORG (David Wright) (10/22/89)
Can anyone give me any advice on doing graphics in a dual-playfield window, with consideration to windows? I would like to do output directly to the screen, and not use windows at all. But if I must use windows, I have a question regarding something like a boarderless, backdrop window in place of the screen. Will ANYTHING in the first playfield which is color 0 show through, even if it is in a window? This would be great as it would solve 2 problems: 1) I can't seem to get rid of the screen title bar/depth gadgets 2) It would let me make intuition redraw the display so I wouldn't have to. What I have is 2 custom bit maps that I want to use for the 2 playfields, but when the ARP file requester appears on the first screen, it trashes the graphics beneath it. The screen title bar overwrites about 10 lines of the top of the display, and reduces the total amount of space for graphics. If I were to do the first playfield the same, but make a single full-screen, borderless, backdrop window, and then use ShowTitle, the effect would be the same. Plus I could set the window up as a SMART_REFRESH, and let intuition take care of the clipping. I could also just set the pointer to the start of the custom bit map for the window instead of the screen. I am getting my custom screen data by using NGI and Br2C to convert an IFF picture to C data statements, and then adding the "chip" keyword to the definitions, and letting the compiler set the hunk to load into chip memory. I don't want to load in an IFF picture, or do any kind of allocate/ allocraster/etc. unless it is absolutely required. The big question: Will color 0 in windows on the front screen of a dual-playfield display show through to the other playfield. If you have any tips, examples, or advice on how to do this, I would appreciate hearing from you..... Dave
rap@peck.ardent.com (Rob Peck) (10/25/89)
In article <1989Oct22.025305.8587@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > > Can anyone give me any advice on doing graphics in a dual-playfield >window, with consideration to windows? I would like to do output directly >to the screen, and not use windows at all. But if I must use windows, >I have a question regarding something like a boarderless, backdrop window >in place of the screen. Will ANYTHING in the first playfield which is >color 0 show through, even if it is in a window? This would be great as >it would solve 2 problems: > 1) I can't seem to get rid of the screen title bar/depth gadgets > 2) It would let me make intuition redraw the display so I wouldn't > have to. > > What I have is 2 custom bit maps that I want to use for the 2 >playfields, but when the ARP file requester appears on the first screen, >it trashes the graphics beneath it. The screen title bar overwrites >about 10 lines of the top of the display, and reduces the total amount of >space for graphics. > If I were to do the first playfield the same, but make a single >full-screen, borderless, backdrop window, and then use ShowTitle, the effect >would be the same. Plus I could set the window up as a SMART_REFRESH, >and let intuition take care of the clipping. I could also just set the >pointer to the start of the custom bit map for the window instead of the >screen. This IS the solution to your problem. > The big question: Will color 0 in windows on the front screen >of a dual-playfield display show through to the other playfield. > YES, most definitely. In the Badge Killer Demo, "Only Amiga" (mine), the final screen has the words ONLY AMIGA rendered into the foreground playfield, as well as four windows, each a separate task, showing various types of graphics. The windows themselves have color 0 as their background color, drawing the graphics in a way that there is often a lot of transparent space in the window. In the second playfield, drawn behind the first, I run a multicolored linebounce at a maximum rate of 60 lines per second, with the erase-me line trailing somewhere about 30 lines behine the draw-me line. This shows off both multitasking and dual playfield pretty well because you can see through Intuition's windows in the foreground playfield. A third layer of the display is provided by Leo Schwab's OING demo, modified to put the 6 boing balls in front of this dual playfield display (in the red and white of course), with music playing all at the same time. There is a whole lot more to the demo -- thats just the final screen -- it is 51K big including someone else's music player embedded from an executable object file which means that we have two sets of startup code in here. Plus three separate picture files totalling 64k, a song SMUS file, and instruments files (totalling 100K). Finally, though not on the demo disk, it'd have played three sampled sound files, one of which was supposed to say (early in the demo) "Daddy ... what's an Amiga?" The quake upset the applecart on the sampling. But the demo is smart enough to have known that if it could not find its sound samples, just skip them and go on. The same with the iff-reader for the M*cPaint picture and the HippoCard picture... no picture, no display. Re your problems with Dual Playfield... I'd suggest that you start with the demo that I posted and modify things one at a time, just so you can see that you can indeed render into the foreground and background areas. When I created that program chunk, I had trouble remembering which was foreground and which was background and had the wrong user copper list "bplcon2" value poked, so that even though I was drawing into the right area, I never saw it. Yet another problem I ran into was forgetting to MakeView to add the second playfield itself. As I said, START with the demo, INTACT, and experiment, adding one feature at a time. NOTICE: the source code to my entire demo, ONLY AMIGA, will be made available at low cost to interested parties. View the demo first, then check out the "CREDITS" file for ordering information. Pricing is yet to be decided --- depends on demand --- high demand, ( >100 inquiries), low price. I'll be redoing the demo to take care of a number of things. Though it seems relatively small right now, I want it to run (or run most of the way) in a 512K machine instead of a 1 Meg machine. Most of that gets fixed by modifying the script so that the INSTRUMENTS: directory should come from disk not from RAM:. By some modifications of the features of the demo, I can make sure that any Amiga owner could run it. By contrast, one of the top level winners of this year's BADGE contest requires an 8 Mb machine for it to load and run and occupies something in excess of 8 floppies to hold it. It is Amiga Trek and essentially duplicates the lead-in to StarTrek, the Original Generation. Rob Peck DATAPATH, POBox 1828, Los Gatos, CA 95031