[comp.sys.amiga] Rapid Stimulus Displaying on the Amiga Help. Solution

dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/20/87)

	Use a two plane screen, then render bitmap A into plane 1, and 
	bitmap B into plane 2 .  The idea is that then all you need to
	do to switch bitmaps is set the color registers:

	plane:	2 1	color register
		0 0	0	always background color
		0 1	1	depends 
		1 0	2	depends
		1 1	3	doesn't matter

	Step 1:	Set all color registers to background color
	Step 2: Render bitmap A into plane 1
		Render bitmap B into plane 2
			(user still sees background color)
		
	Remember that when you do a SetRGB4(), the new colors don't take
	effect until the vertical retrace gets back to the top (and the
	Copper reloads the color registers).

	Step 3: WaitTOF(), set register 1 = COLOR, 2 = BACKGROUND
		(user still sees background since you missed the copper reload)
	Step 4: WaitTOF(), set register 1 = BACKGROUND, 2 = COLOR
		Here, the copper had just loaded 1 = COLOR, 2 = BACKGROUND,
		so the user sees plane 1.  On the next retrace, the user will
		see plane 2.

	Step 5: WaitTOF(), set register 1 = COLOR, 2 = BACKGROUND
		Again, even though you're using SETRGB4() to set the color,
		it happens AFTER the copper has loaded the color registers.

		continue this way until done.
		

	The real neat thing about this method of doing things is that your
	process has an entire 1/60th of a second after the WaitTOF() returns 
	to make the changes to the colormap with SetRGB4().  Needless to say,
	this means you can run the program without a Forbid()/Permit().

					-Matt
		

fdfishman@watcgl.UUCP (04/21/87)

In article <8704200221.AA03819@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>
>	Use a two plane screen, then render bitmap A into plane 1, and 
>	bitmap B into plane 2 .  The idea is that then all you need to
>	do to switch bitmaps is set the color registers:
>
>	plane:	2 1	color register
>		0 0	0	always background color
>		0 1	1	depends 
>		1 0	2	depends
>		1 1	3	doesn't matter
                ^^^^^^^ ^^^^^
colour 3 does matter, since it represents the intersection of the two stimulus, if you set this colour
to 0 then, where ever the two stimulus intersect you will see a missing hole.  As well if you set 3 to white
when you draw the stimulus, you see a white area before you want to display the object.  So want to know the
simple solution?  When you display a plane make sure you also enable colour 3.

This method of drawing into two planes is a very good one, but why stop at two planes, you have 5 to play
with, therefore you can display 5 stimulus, all you have to do when writing the stimulus is enable the
write mask so that only the desired plane is written to (i.e. RastPort.Mask = 1 << plane).

Then to display each plane you can use a simple routines like:

   DisplayPlane(view, plane)
   struct ViewPort *view;
   int plane;
      {
	  int loop;

	  for (loop = 0; loop < 2^NUMPLANES; loop++)
          {
		  if ( (loop & (1<<plane) ) == 0) SetRGB4(view, loop, 0, 0, 0);
		  else SetRGB4(view, loop, REDON, GREENON, BLUEON);
		  }
	  }

DisplayPlane enables all the colours that effect the displayed plane and turns all the other colours 0


>
>					-Matt
>		
-- 
FDFISHMAN (Flynn D. Fishman) @ WATCGL (but you can call me Flynn)
	UUCP  :	...!{decvax|ihnp4|clyde|allegra|utzoo}!watmath!watcgl!fdfishman
	ARPA  : fdfishman%watcgl%waterloo.csnet@csnet-relay.arpa2
	CSNET :	fdfishman%watcgl@waterloo.csnet

dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/21/87)

>>	plane:	2 1	color register
>>		0 0	0	always background color
>>		0 1	1	depends 
>>		1 0	2	depends
>>		1 1	3	doesn't matter
>                ^^^^^^^ ^^^^^
>colour 3 does matter, since it represents the intersection of the two stimulus, if you set this colour

	Oops, your right.  Color 3 should be set to whatever color you are
using for the current bitmap... i.e. equal to either 1 or 2 depending on which
bitmap your displaying:

		color reg
		0	background
		1	pen A
		2	background
		3	pen A

		color reg
		0	background
		1	background
		2	pen B
		3	pen B

		where A may or may not be the same as B... whatever you choose.

		-Matt

rap@dana.UUCP (04/22/87)

To do rapid screen updating and not fool around with ScreenToFront and so on,
Matt suggests the following:

In article <8704200221.AA03819@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> 
> 	Use a two plane screen, then render bitmap A into plane 1, and 
> 	bitmap B into plane 2 .  The idea is that then all you need to
> 	do to switch bitmaps is set the color registers:
> 
> 	plane:	2 1	color register
> 		0 0	0	always background color
> 		0 1	1	depends 
> 		1 0	2	depends
> 		1 1	3	doesn't matter
> 
> 	Step 1:	Set all color registers to background color
> 	Step 2: Render bitmap A into plane 1
> 		Render bitmap B into plane 2
> (more)
>	(.... talking about using SetRGB4 to alternate which of
>	      two color registers gets the non-background color)

First, congratulations Matt... I was going to work out some whizbang
swapping of pointers (not necessarily, but possibly Intuition-compatible)
that would do the task, but you found a simpler and more general method.

But... (tiny one, but important), this must be a monocolor technique,
where the color in register 3 DOES matter if the user wants to effectively
be double-buffering.  That is, if he draws into the invisible plane
while displaying the visible one, then there could easily be places
where the bits of plane 2 and plane 1 would overlap, thereby selecting
color number 3.  Thus:

	color register 0 = background color always.

	While drawing into plane 1:
		color register 1 = background color (so is not seen)
		color register 2 = COLOR (being displayed)
		color register 3 = COLOR (being displayed)

					so that any bits coincident
					between plane 1 and plane 2
					select color 3 which is the
					same as the color currently
					being displayed.

But, again, a neat way of attacking the problem!

Rob Peck		...hplabs!dana!rap