[comp.sys.amiga.programmer] How to use BPLCON2?

aaron@stat.tamu.edu (Aaron Hightower) (02/15/91)

Today, I was working on one of my programs that uses both sprites and menus
on the same screen.  The problem that I ran into was when I tried to use the
menus.  When the menu is pulled down, the sprite(s) overlap the menu.  I
read in the RKM Hardware manual and found the chapter on how to set the
playfield-sprite priorities, and it mentions that you can use BPLCON2 to
set the priorities.  For a 1-Playfield screen, you are supposed to use
bits 3,4, and 5.  I tried what the manual suggested, but nothing appeared
to change.  The sprites still overlapped my menus.  So how can I do this? 
Can I set some flags in the NewScreen structure or something?  Am I writing
to the wrong place (I am using 0x104 for BPLCON2?)

The other thing that I tried (first) was to read the MENUBUTTON, MENUDOWN
event from my IDCMP port, but since Intuition evidently processes the right
button for the menus, it is not accessible (is absorbed and not passed 
through the IDCMP port.)  It mentioned that you could do a RMBTRAP, but that
this would temporarily disable the menu.

I am sure that this can be done.  I believe that AudioMaster does this,
because they use sprites for their little range thingymadoppers...
Is there a little bit of code that I could insert to do the RMBTRAP, and still
have the menus work normally?

Mucho gracious,
  Aaron Hightower

jesup@cbmvax.commodore.com (Randell Jesup) (02/15/91)

In article <12181@helios.TAMU.EDU> aaron@stat.tamu.edu (Aaron Hightower) writes:
>Today, I was working on one of my programs that uses both sprites and menus
>on the same screen.  The problem that I ran into was when I tried to use the
>menus.  When the menu is pulled down, the sprite(s) overlap the menu.  I
>read in the RKM Hardware manual and found the chapter on how to set the
>playfield-sprite priorities, and it mentions that you can use BPLCON2 to
>set the priorities.  For a 1-Playfield screen, you are supposed to use
>bits 3,4, and 5.  I tried what the manual suggested, but nothing appeared
>to change.  The sprites still overlapped my menus.  So how can I do this? 
>Can I set some flags in the NewScreen structure or something?  Am I writing
>to the wrong place (I am using 0x104 for BPLCON2?)

	Graphics is probably resetting BPLCON2 every vertical blank.  Remember
that the hardware tells you what the hardware does, not how that interacts
with the system software.  You may be able to do it using a user copper
list to set the mode.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)

spence@cbmvax.commodore.com (Spencer Shanson) (02/16/91)

In article <18999@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>In article <12181@helios.TAMU.EDU> aaron@stat.tamu.edu (Aaron Hightower) writes:
>>Today, I was working on one of my programs that uses both sprites and menus
>>on the same screen.  The problem that I ran into was when I tried to use the
>>menus.  When the menu is pulled down, the sprite(s) overlap the menu.  I
>>read in the RKM Hardware manual and found the chapter on how to set the
>>playfield-sprite priorities, and it mentions that you can use BPLCON2 to
>>set the priorities.  For a 1-Playfield screen, you are supposed to use
>>bits 3,4, and 5.  I tried what the manual suggested, but nothing appeared
>>to change.  The sprites still overlapped my menus.  So how can I do this? 
>>Can I set some flags in the NewScreen structure or something?  Am I writing
>>to the wrong place (I am using 0x104 for BPLCON2?)
>
>	Graphics is probably resetting BPLCON2 every vertical blank.  Remember
>that the hardware tells you what the hardware does, not how that interacts
>with the system software.  You may be able to do it using a user copper
>list to set the mode.
>
>-- 
>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
You beat me to it, Randell. Yes, graphics.library does change (reset) the BPLCON2
register every VBlank. As Randell says, you will need to install your own
user copper list in your viewport to get your effect.



-- 
---------------------------------------------------------------------------
Spencer Shanson - Amiga Software Engineer     | email: spence@commodore.COM
                                              | or uunet!cbmvax!spence
All opinions expressed are my own, and do not | "You know my methods. Apply
(necessarily) represent those of Commodore.   | them" -- Sir Arthur Conan
                                              | Doyle - 'The Sign of Four'

jsmoller@jsmami.UUCP (Jesper Steen Moller) (02/16/91)

In article <12181@helios.TAMU.EDU>, Aaron Hightower writes:

> Today, I was working on one of my programs that uses both sprites and menus
> on the same screen.  The problem that I ran into was when I tried to use the
> menus.  When the menu is pulled down, the sprite(s) overlap the menu.
> [hardware stuff deleted]
> 
> The other thing that I tried (first) was to read the MENUBUTTON, MENUDOWN
> event from my IDCMP port, but since Intuition evidently processes the right
> button for the menus, it is not accessible (is absorbed and not passed 
> through the IDCMP port.)  It mentioned that you could do a RMBTRAP, but that
> this would temporarily disable the menu.

You are on the right track:

Use the IDCMP-code MENUVERIFY. You will get this message when the user presses
the right mouse button. When you recieve the message, remove the sprites.
Then when you recieve MENUPICK, put the sprites back in place.

WARNING: Do not use any funtion that calls a DOS function or put up a requester
or whatever, without turning the MENUVERIFY off. Otherwise, you get a ever-
so popular Intuition deadlock. Intuition waiting for you to reply to MENUVERIFY,
user trying to answer the requester, but fails, because he/she pressed the right
button, and Intuition can't do anything.

So, to make it all work without errors:

ModifyIDCMP(window,SAFEIDCMP

Where SAFEIDCMP has _no_ xxxxVERIFY flags.
BEFORE caling any AutoRequesters, EasyRequests (2.0), DOS calls, or things like:
OpenDiskFont, OpenDevice, OpenLibrary, AvailFonts, etc. - these functions call
DOS routines, and there you go. Whack! Mouse freezes if MENUBUTTON is pressed.

If this is too dull, I'm sure the Commodore folks will add comments, if I have
missed anything vital.

I use this technique in my IFFMaster 1.0 (an IFF-converter that handles many
things, totally interactively and system-friendly) and if I'm not mistaken,
that's how DPaint does.

> Mucho gracious,
>   Aaron Hightower

Nothing, really :)

Jesper S Moller
(Denmark)

--                     __
Jesper Steen Moller   ///  VOICE: +45 31 62 46 45
Maglemosevej 52  __  ///  USENET: cbmehq!cbmdeo!jsmami!jsmoller
DK-2920 Charl    \\\///  FIDONET: 2:231/84.45
Denmark           \XX/  OPINIONS: Certainly!

dale@boing.UUCP (Dale Luck) (02/17/91)

In article <12181@helios.TAMU.EDU> aaron@stat.tamu.edu (Aaron Hightower) writes:
> When the menu is pulled down, the sprite(s) overlap the menu.  I
>read in the RKM Hardware manual and found the chapter on how to set the
>playfield-sprite priorities, and it mentions that you can use BPLCON2 to
>I tried what the manual suggested, but nothing appeared
>to change.  The sprites still overlapped my menus.  So how can I do this? 

You need to set the byte called "SpritePriorities" in the ViewPort
structure. When the ViewPort is initialized, a value is put in there
that means sprites on top. Change it to what you want. The next time
the system needs to remake the copper list for your viewport, it will
use this value.

-- 
Dale Luck     GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dale

dej@qpoint.amiga.ocunix.on.ca (David Jones) (02/18/91)

>In article <12181@helios.TAMU.EDU> aaron@stat.tamu.edu (Aaron Hightower) writes:
>Today, I was working on one of my programs that uses both sprites and menus
>on the same screen.  The problem that I ran into was when I tried to use the
>menus.  When the menu is pulled down, the sprite(s) overlap the menu.  I

Try MENUVERIFY.  If you tell your window to MENUVERIFY, you will get a
message from the IDCMP every time the user tries to pull a menu.  You
simply kill the sprites and reply to the message.  When the user finishes
with the menu, you will get a menu message (at least MENUNULL if no
selection was made) at which point you turn the sprites back on.  Consult
the RKM on MENUVERIFY for more details.

--
 
 |    The Q-Point                  David Jones
 |\   Amiga S/W development        UUCP:  dej@qpoint.amiga.ocunix.on.ca
 | \                               Fido:  1:163/109.8                  
 |  \
 |   \      "I can understand why someone would want to go out, get drunk
 |   -\----  and wake up the next morning with a splitting headache and
 |  /  \     absolutely no memory of the night before, but I *cannot*
 | /    \    understand why anyone would want to do that more than once."
 |/      \
 +----------                                   - Don Elgee