Double Buffering
Eric Chet
I have a problem. I have a intuition screen, with many gadgets on it.
The screen is 2 bit planes, 640x400 interlaced. I have a rectangular
region of the screen (14,12)-(490,385) that I need to do 30 frames per
second animation on. My problem is double buffering that region. I
should be able to create, 2 alternative BitMaps(for that region) and
2 copper instruction streams, One displaying the first alternative region,
the other displaying the second alternative region. Then it's just swaping
the copper instruction lists.
What copper instructions, really what custom registers do I need to
write to, and what do I need to write to them to accomplish this?
Thank You in advance -- I hope there are some copper junkies out there.
Eric Chet -- Internet: ch...@netcom.com
BIX: chet
--
~
/**************************************************************************
* Eric Chet | Amiga does it better
* ch...@netcom.com | Ray Tracing and other graphics techniques
* BIX: chet | "Use what is useful, simply to simplify"
*/
mr s.d. twyford
>Hello
>
> I have a problem. I have a intuition screen, with many gadgets on it.
>The screen is 2 bit planes, 640x400 interlaced. I have a rectangular
>region of the screen (14,12)-(490,385) that I need to do 30 frames per
>second animation on. My problem is double buffering that region. I
>should be able to create, 2 alternative BitMaps(for that region) and
>2 copper instruction streams, One displaying the first alternative region,
>the other displaying the second alternative region. Then it's just swaping
>the copper instruction lists.
>
> What copper instructions, really what custom registers do I need to
>write to, and what do I need to write to them to accomplish this?
Before you decide to write to the copper registers, you need to
consider a few facts. Firstly, Intuition uses the graphics library privitives
to generate copper lists for its sreens. Intuition has a its own View structure
in IntuitionBase, so if you use the graphics privitives to create your own
view structure, and call LoadView(), Intuition's view will disappear and
you will have taken over the display.
Further more, the graphics library creates its own copper lists and
writes directly to the copper registers, so if you write to the copper
registers, you will take over the copper hardware from any program (such as
Intuition) that was using it through the graphics library.
To double buffer under Intuition, you need to open two screens,
one for each buffer, and then swap the screens by calling ScreenToFront(),
(I think, you may get a posting from me after I check that). This will mean
you will have to split your screen in two, the part you want double buffered
and the part you don't want double buffered. To do gadgets on a double buffered
screen you would have to get intuition to render the gadget window into both
screens (?). There is a problem with this method, it is very slow. This
is because whenever the screens are ordered, moved, etc. Intuition has to
create a new copper list for its view, this will occur every time you swap
your screens.
It is much easier to double buffer using the graphics privitives,
just create two view structures and swap them with LoadView(), however this
will block out Intuition. In your case you could initialise three ViewPort
sturctures, (1) The ViewPort for the first buffer of the double buffered
screen, (2) The second buffer and (3) the ViewPort for the screen with the
gadgets. Then set up two View structures, one with ViewPort (1) and (2),
one with ViewPort (1) and (3). How you would trick Intuition into rendering
into you custom View and ViewPort structures, I don't know. You may have
to write your own gadget routines.
The copper method is much the same as the Graphics Library method,
except has fewer advantages and more disadvantages.
>
>Thank You in advance -- I hope there are some copper junkies out there.
Your Welcome.
>
>Eric Chet -- Internet: ch...@netcom.com
> BIX: chet
>--
>~
>/**************************************************************************
> * Eric Chet | Amiga does it better
> * ch...@netcom.com | Ray Tracing and other graphics techniques
> * BIX: chet | "Use what is useful, simply to simplify"
> */
Stuart Twyford.
Internet: int...@monu4.cc.monash.edu.au
Neil Richmond
1.3. The problem is that when I got my A3000 with 2.0, my program broke. I
have checked all phases of my program and the problem seems to occur when I
access the input.device. A couple of notes, I use IECLASS_POINTERPOS instead
of RAWMOUSE. I do this because I get absolute coordinates from the tablet. I
then transform the coodinates of the tablet to 600X400 space. I handle the
buttons in a separate input to input.device. Of course, the coordinates are
passed at that time and they are passed if no button is activated. The problem
is the mousepointer moves, even if the pen is not moving. Eventually, it moves
to the lower right corner of the screen, as if the values it is getting is a
deltax and deltay, not absolute screen coordinates, until it reaches the
maximum values. This program use to and still does work under 1.3. I need help.
Is this enough info, or should I post the program. I haven't because I don't
want to waste net resources. My references have been RKM 1.3 and Ed Hanway's
OptMouse Program that was on Fred Fish Disk #445.
neil
--
Only 3132 shopping days left till the next millenium!
Neil F. Richmond INTERNET: celia!ne...@usc.edu
Rhythm & Hues Inc. UUCP: ...{ames,hplabs}!lll-tis!celia!neil)
Valentin Pepelea
>
>A couple of notes, I use IECLASS_POINTERPOS instead
>of RAWMOUSE.
>
>Eventually, it moves to the lower right corner of the screen, as if the
>values it is getting is a deltax and deltay, not absolute screen coordinates,
>until it reaches the maximum values.
Every time, before you send the input device a fake input event, you are
supposed to re-initialize all fields of the InputEvent structure. Under 1.3
you could get away without doing this. Under 2.0, the ie_Class field gets
trashed.
This has been fixed under more recent releases of 2.0. Consider yourself lucky
this shmuk ran into the problem first. :-) :-(
Valentin
--
"An operating system without virtual memory Name: Valentin Pepelea
is an operating system without virtue." Phone: (408) 985-1700
Usenet: mips!btr!valentin
- Ancient Inca Proverb Internet: vale...@btr.com
Peter Cherna
>1.3. The problem is that when I got my A3000 with 2.0, my program broke. I
>have checked all phases of my program and the problem seems to occur when I
>access the input.device. A couple of notes, I use IECLASS_POINTERPOS instead
>of RAWMOUSE.
The 1.3 RKM manual states explicitly that you must not rely on data you
place in an InputEvent remaining unmodified for your later use (see
p. 698). It turned out that under 1.3, the contents of IECLASS_POINTERPOS
happened to be preserved. For compatibility, recent versions of 2.0
now preserve those fields as well.
A second issue is that the include files have defined the mouse-button
codes (IECODE_LBUTTON, etc.) as being for the IECLASS_RAWMOUSE event,
but many people sent them (incorrectly) for IECLASS_POINTERPOS. Under
1.3, that happened to work (because IECLASS_POINTERPOS was coverted
very simply into IECLASS_RAWMOUSE). Under 2.0, the handling of input
events is more sophisticated, and this side-effect was lost. Again,
because of the number of people who depended on this and the fact
that the side-effect could be easily re-created without much burden
to Intuition, a change was made so things work like they did in 1.3.
In any case, the last public release of 2.0 (2.03) still has this
problem. You'll have to wait (not long, hopefully) for 2.04 to
cure this problem.
Alternately, since you wrote the driver, you could fix it to
tide you over in the meantime.
>neil
Peter
--
Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter pe...@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"If all you have is a hammer, everything looks like a nail."
Neil Richmond
>this shmuk ran into the problem first. :-) :-(
>
>Valentin
>--
I resent this remark.
neil
--
Only 3127 shopping days left till the next millenium!
Peter Cherna
>>this shmuk ran into the problem first. :-) :-(
> ^^^^^
>>
>>Valentin
>>--
>
>I resent this remark.
You don't need to resent it. He was talking about himself. (He reported
the change in behavior to us, and we fixed it so it works like it
used to).
>Neil F. Richmond INTERNET: celia!ne...@usc.edu
Peter
--
Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter pe...@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
"Gosh, didn't he have anything positive to say at all?"
Valentin Pepelea
>writes:
>>
>>this shmuk ran into the problem first. :-) :-(
> ^^^^^
>I resent this remark.
>
>neil
I was referring to myself. Double-check the context of that statement.
baxt...@wehi.dn.mu.oz
> In article <29...@public.BTR.COM> vale...@public.BTR.COM (Valentin Pepelea) writes:
>>this shmuk ran into the problem first. :-) :-(
> ^^^^^
>>
>>Valentin
>>--
>
> I resent this remark.
>
> neil
Why? It seems to me that V was calling himself a shmuk (whatever that is),
so I'm sure he didn't mean any harm by it.
Regards Alan
Neil Richmond
>A second issue is that the include files have defined the mouse-button
>codes (IECODE_LBUTTON, etc.) as being for the IECLASS_RAWMOUSE event,
>but many people sent them (incorrectly) for IECLASS_POINTERPOS. Under
>1.3, that happened to work (because IECLASS_POINTERPOS was coverted
>very simply into IECLASS_RAWMOUSE). Under 2.0, the handling of input
If this was incorrect, what is correct? To use IECLASS_RAWMOUSE whenever
I am sending mouse key events and IECLASS_POINTERPOS whenever I send x
and y coordinates to the mousepointer? There is VERY LITTLE reference to
IECLASS_POINTERPOS in the RKM1.3 Manuals. I read that IECLASS_POINTERPOS
was converted anyway in RAWMOUSE with the correct relative values. What
happens in 2.0?
>events is more sophisticated, and this side-effect was lost. Again,
>because of the number of people who depended on this and the fact
>that the side-effect could be easily re-created without much burden
>to Intuition, a change was made so things work like they did in 1.3.
Is it a good thing that side effect was lost? My own feeling is that I would
rather do things correctly, than have some kind of repair made so what I did
wrong, in the first place, will still work. Obviously, I am not the only one
who made this mistake, although I might have been the only one who made it
out of ignorance. Where can I find more information about this?
>Alternately, since you wrote the driver, you could fix it to
>tide you over in the meantime.
I am trying to make this fix. This does help a lot. Thanks.
neil
--
Only 3127 shopping days left till the next millenium!
Peter Cherna
>If this was incorrect, what is correct? To use IECLASS_RAWMOUSE whenever
>I am sending mouse key events and IECLASS_POINTERPOS whenever I send x
>and y coordinates to the mousepointer? There is VERY LITTLE reference to
>IECLASS_POINTERPOS in the RKM1.3 Manuals. I read that IECLASS_POINTERPOS
>was converted anyway in RAWMOUSE with the correct relative values. What
>happens in 2.0?
IECLASS_POINTERPOS now officially supports IECODE_xBUTTON stuff. It
did in 1.3, lost it in early 2.0 (it fell out because it wasn't
defined to work), and now once again does. It will continue to do so.
>Is it a good thing that side effect was lost?
The side-effect is back, and it does no harm to the system to leave it
that way. You may continue to use IECLASS_POINTERPOS with IECODE_xBUTTON,
since most everyone that has 2.0 will end up with 2.04 soon.
>Neil F. Richmond INTERNET: celia!ne...@usc.edu
Peter
--
Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter pe...@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
Neil Richmond
I just wanted to say thanks. With your info, I got my tablet up and running
again under 2.0. I still would like more information on IECODE_LBUTTON, etc
and their relation to IECLASS_POINTERPOS. If you could point out some
references in this area, I would appreciate it very much. Thanks.
neil
--
Only 3126 shopping days left till the next millenium!
Peter Cherna
>
>I just wanted to say thanks. With your info, I got my tablet up and running
>again under 2.0. I still would like more information on IECODE_LBUTTON, etc
>and their relation to IECLASS_POINTERPOS. If you could point out some
>references in this area, I would appreciate it very much. Thanks.
The RKM doesn't have anything direct to say about IECODE_LBUTTON and
friends. The entire reference seems to be <devices/inputevent.h>:
/* IECLASS_RAWMOUSE */
#define IECODE_LBUTTON 0x68 /* also uses IECODE_UP_PREFIX */
#define IECODE_RBUTTON 0x69
#define IECODE_MBUTTON 0x6A
#define IECODE_NOBUTTON 0xFF
The comment will get changed to:
/* IECLASS_RAWMOUSE and IECLASS_POINTERPOS */
>Neil F. Richmond INTERNET: celia!ne...@usc.edu
Peter
--
Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter pe...@cbmvax.commodore.com
My opinions do not necessarily represent the opinions of my employer.
Neil Richmond
>the change in behavior to us, and we fixed it so it works like it
>used to).
Apologies to Valentin and everyone else in the net. That was not clear to me.
neil
--
Only 3125 shopping days left till the next millenium!
Neil F. Richmond INTERNET: celia!ne...@usc.edu