[net.micro.amiga] Making a screen invisible

pacs4900@oswego.UUCP (Mark Reichert) (10/14/86)

[ these bits may never been seen again, how sad... ]

 Does anyone know how to make a screen not be displayed? I have a program
that makes pictures and is capable of saving it's screen itself, and
would just as soon not have my cycles stolen while the program is running
( it runs for n hours ). It is a 4 plane hires interlaced, and I don't really
need to see it as it runs.

					Thanx in advance.
					mark

chiu@princeton.UUCP (Kenneth Chiu) (10/14/86)

In article <776@oswego.UUCP> pacs4900@oswego.UUCP (Mark Reichert) writes:
>Does anyone know how to make a screen not be displayed?. . .[I] would just as
>soon not have my cycles stolen while the program is running. . .

I'm not exactly sure what you mean, but you could always just close the screen.
Or you could move the top of the screen all the way to the bottom.  You could
also move the screen behind other screens (such as the Workbench screen).
There are many things you could do.  Mail me if you want the actual calls.

On a different subject, can someone tell me how to call the ChangePri function?
It's mentioned in the chapter on tasks in the RKM, but the arguments aren't
given there, or in the autodocs.  Thanks.
-- 
Kenneth Chiu                                              UUCP: princeton!chiu
Princeton University Computer Science Department        BITNET: 6031801@PUCC

dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/14/86)

	I dunno, you could simply move the screen down via (I think,
MoveScreen)... simply move it to the very bottom of the screen. Even better,
You can simply move your workbench screen over your custom one.  It's only
what you see that uses CPU cycles.

					-Matt

carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (10/15/86)

In article <776@oswego.UUCP> pacs4900@oswego.UUCP (Mark Reichert) writes:
>[ these bits may never been seen again, how sad... ]
>
> Does anyone know how to make a screen not be displayed? I have a program
>that makes pictures and is capable of saving it's screen itself, and
>would just as soon not have my cycles stolen while the program is running
>( it runs for n hours ). It is a 4 plane hires interlaced, and I don't really
>need to see it as it runs.
>
>					Thanx in advance.
>					mark


   A simple way would be to open a 1 bitplane lo-res screen in front of
your hi-res screen.  Or use ScreenToBack() to push your screen behind
the WB screen.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Carolyn Scheppner -- CBM   >>Amiga Technical Support<<
                     UUCP  ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn 
                     PHONE 215-431-9180
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

miner@ulowell.UUCP (Richard Miner) (10/16/86)

In article <776@oswego.UUCP> pacs4900@oswego.UUCP (Mark Reichert) writes:
> Does anyone know how to make a screen not be displayed? I have a program
>( it runs for n hours ). It is a 4 plane hires interlaced, and I don't really
>need to see it as it runs.

Mark, why don't you just do your rendering directly to a file?  This would
not use any system memory for the image.  Since it sounds like it takes quite
a while to render each pixel you could open the file and append each pixel
as it is calculated.  If you really want to render the image in a bitplane, 
if for instance new pixel values are somehow dependent on previous pixels,
you can build your own bitmap and render into that.  Look into the 
AllocRaster command.  Then you can save this and or use one of the blt
routines to blit the bitmap to a hires interlaced rastport.

UUCP: !wanginst!ulowell!miner    Rich Miner
ARPA: miner@ulowell.CSNET        University of Lowell, Comp Sci Dept
TALK: (617) 452-5000 x2693       Lowell MA 01854 USA
HAL hears the 9000 series is not selling. "Please explain Dave. Why 
aren't HAL's selling?"  Bowman hesitates. "You aren't Amiga compatible."

phillip@cbmvax.cbm.UUCP (Phillip Lindsay) (10/16/86)

> 
> On a different subject, can someone tell me how to call the ChangePri function?
> It's mentioned in the chapter on tasks in the RKM, but the arguments aren't
> given there, or in the autodocs.  Thanks.
> -- 
> Kenneth Chiu                                              UUCP: princeton!chiu
> Princeton University Computer Science Department        BITNET: 6031801@PUCC
>

I believe there was a document error someplace, but anyways:

SetTaskPri() is what you want...look in exec.doc (vol.2 rkm)

HINT: ALWAYS REFER TO VOL.2 RKM ... THE DOC'S ARE EXTRACTED FROM THE SOURCE.


==============================================================================
  Phillip Lindsay - Commodore Business Machines - Amiga Technical Support
    Dirt: 1200 Wilson Drive, West Chester  PA 19380                
    uucp: {ihnp4|seismo|caip}!cbmvax!phillip
    arpa: cbmvax!phillip@seismo -or- phillip@cbmvax.UUCP@{seismo | harvard}
    Tel.: (215) 431-9180
Disclaimer: [someone said I needed this] No warranty is implied or otherwise
   given in the form of suggestion or example. Any opinions found here are of
   my making. [unless Fred pops up (my other self)] 
==============================================================================

danny@convex.UUCP (10/17/86)

I think he's talking about clearing out the bits of the screen.

I don't have my manuals here but isn't there a specific function just
for the purpose?  C-A?

Dan Wallach

toebes@sas.UUCP (John Toebes) (10/17/86)

In article <776@oswego.UUCP> pacs4900@oswego.UUCP (Mark Reichert) writes:
>Does anyone know how to make a screen not be displayed?. . .[I] would just as
>soon not have my cycles stolen while the program is running. . .

POPCLI does exactly this when it shuts down the screen.  It first opens a small
screen in lores with a black background.  It then shuts down the DISPLAY with
the OFF_DISPLAY macro.  The sources were posted to mod.amiga about a week ago.
The basic code is:

#include <graphics/gfxmacros.h>
#include <hardware/custom.h>
#include <hardware/dmabits.h>
...
extern struct Custom custom;
struct NewScreen      NewScreen = 
   { 0, 0, 320, 30, 1, 0, 1, NULL, CUSTOMSCREEN, NULL, NULL, NULL, NULL };
extern struct Screen   *OpenScreen(), *myscreen;

   if ((myscreen = OpenScreen(screen)) != NULL)
      {
      /* set the background color to black.  this is the color that is */
      /* displayed when the display is turned off */
      SetRGB4(&(global.blankscreen->ViewPort), 0, 0, 0, 0);
      /* turn off the display - this gives cycles back to the 68000 AND sets */
      /* the screen to the current background color */
      OFF_DISPLAY

      (void) CloseScreen(global.blankscreen);
      ON_DISPLAY
      }

Note that opening the separate screen is a convenience on my part.  It is
easier than having to locate, save and restore the current background color.
-- 
John A. Toebes, VIII       usenet:..mcnc!rti-sel!sas!toebes
USnail: 235 Trillingham Ln, Cary NC 27511   BBS:(919)471-6436

jacs4440@oswego.UUCP (Dan/Mark) (10/21/86)

In article <93500054@convex> danny@convex.UUCP writes:
>
>I think he's talking about clearing out the bits of the screen.
>
>I don't have my manuals here but isn't there a specific function just
>for the purpose?  C-A?
>
>Dan Wallach

 No, that really isn't what I was interested in. I guess that I probably
didn't express what I needed well enough. What I want is to be able to
do rendering to an INTERLACED screen in memory, with as little ( ideally
none ) effect on the display as possible. I don't like an interlaced
workbench, and this program could run for quite a few hours ( days even ).
What I had in mind, and I guess that I am dreaming is something such as :

	scr = OpenScreen(&ns); /* everything gets interlaced */
	win = OpenWindow(&nw);
	bit-twiddle, hand-wave, hocus-pocus, linked list kludge;
	[Remake/Rethink]Display(); /* because these look at everything ?? */

 and suddenly, the new screen goes away and my workbench un-interlaces. Now,
I can Move() and Draw() and all sorts of other neat stuff, and when the
picture is done, it will write the picture out to disk. I also may need a
sequence for closing this invisible screen.
 I Hope it's clearer this time.

				- mark

dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/27/86)

>No, that really isn't what I was interested in. I guess that I probably
>didn't express what I needed well enough. What I want is to be able to
>do rendering to an INTERLACED screen in memory, with as little ( ideally
>none ) effect on the display as possible. I don't like an interlaced
>workbench, and this program could run for quite a few hours ( days even ).
>What I had in mind, and I guess that I am dreaming is something such as :

	<sigh>  All you need do graphics rendering is a rastport... you don't
need to open any screens or anything like that... just setup the
fields properly in the rastport, allocate a bitmap (read carefully RKM V1
on graphics... If I remember right, rastports for interlace screens are
slightly different).  All bitmap memory must, of course, be CHIP.  When
you are through rendering it shouldn't be too difficult to open an interlace
display and simply transfer the info... in fact, I think you can even
specify you have a custom bitmap and use the same bitmap you used for
the original rendering.

	I've never specifically tried doing this myself.  Good Luck.

	
					-Matt