🚀 go-pugleaf

In article <664@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes:
>In article <4189@mindlink.UUCP> a976@mindlink.UUCP (Ron Tarrant) writes:
>>
>>I took a look at the code for MultiPlot and unfortunately it doesn't do the
>>kind of thing I'm trying to do. Like you said, it will create an overscan
>>screen IF the WB screen is overscan (set by MoreRows, et al). What I want to do
>>is create an overscan display from scratch so that the end product doesn't
>>depend on MoreRows or something else to set up the overscan screen.
>>
>>Is there an OFFICIAL CBM  way of doing this?
>
>You must (upgrade to/wait for) 2.0 where there is an OFFICIAL way for
>doing overscan.
>
>-- 
>Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
>Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

Okay.  I have WB2.0.  I have a similar problem.  I have a game that uses
sprites.  I have recently found that WB2.0 on the Amiga 3000 has very many
different things that a program must consider when loading from the workbench.

1) I have not been able to, as of yet, get sprite#7 (the last one) of the
hardware sprites to appear at all on the Amiga 3000.

2) When using Overscan from the Workbench before loading my game, the # of
sprites available is inversely proportional to the amount of overscan
available from the workbench.  I have, since then, found that this is a problem
with "bandwidth" shared by (or something similar to being shared) screen
and sprite display hardware.  EG: In maximum overscan, I can only display
sprites 0 (pointer) thru 4 (or 5 - don't quite remember.)

3) When using SuperBitMap features of the display, (particularly ones that
involve horizontal scrolling) sprites 4 and 5 start to go crazy.  It is a bit
like a fireworks display, but only 16 pixels wide on the horizontal position
of the sprite (4 or 5).


I have found these sprite problems to be very annoying.  Someone suggested that
the sprite 4/5 problem may be a defect in my particular machine - but they work
fine when I am not on a SuperBitMap screen that scrolls horizontally.

I think that I could prevent problem 2 by using CloseWorkBench() and
OpenWorkbench and/or changing the OverScan values - I suppose I'll do some
grepping for a routine in the 2.0 compiler headers and some more research on
that (any ideas?)

So, C=, what's the story on Amiga3000 sprites?  Am I an isolated case?  Am I
doing something wrong?  Is there a simple solution?  Anyone?