Smooth Scroll and Sprite Channel 7

[Shatterhand]

I am doing some tests here....

Whenever I set my screen (using initcoplist) to use Smooth Scrolling, I can't get sprite channel 7 to show.

Is there anyway to do it? From what I understand, when a sprite doesn't show up is because there's no more DMA time left for it. I didn't know smooth scrolling would affect that though. I've read something about shrinking the display width a little bit to use less DMA, but I have no idea of how any of this works.

Is there anything that can be done?

[Raislin77it]

Originally Posted by Shatterhand

I am doing some tests here....

Whenever I set my screen (using initcoplist) to use Smooth Scrolling, I can't get sprite channel 7 to show.

Is there anyway to do it? From what I understand, when a sprite doesn't show up is because there's no more DMA time left for it. I didn't know smooth scrolling would affect that though. I've read something about shrinking the display width a little bit to use less DMA, but I have no idea of how any of this works.

Is there anything that can be done?

from the manual :

SmoothScrolling
By setting the smooth scrolling flag the extended form of DisplayBitmap may be used which allows the bitmap to be displayed at any offset. This enables the programmer to scroll the portion of the bitmap being displayed. See BlitzMode programming chapter for an explanation of hardware scrolling.

Notes:

* Always use the extended form of DisplayBitmap with smoothscrolling set, even when offset is 0,0.

* DisplayBitmap accepts quick types for the x offset and will position the
bitmap in fractions of pixels on AGA machines.

* The width of the display will be less than the default 320/640/1280 when smooth scrolling is enabled.

yes, reduce the display

DisplayAdjust CopList#,fetchwid,dUfstrt,dUfstop,diwstrt,diwstop 127
Temporary control of display registers until I get the width adjust parameter working
with InitCopList. Currently only standard width displays are available but you can modify the width manually (just stick a screwdriver in the back of your 1084) or with some knowledge of Commodores AGA circuitry. No to be quite serious I really do not have a clue how they cludeged up the Amiga chip set. When ECS was introduced suddenly all display fetching moved to the right. Now they seem to have done the same to sprites so it is near impossible to have them all going without limiting yourself
to a seriously thin display.
If you hack around with the system copperlists you'll find they actually change fetch modes as you scroll a viewport across the display and commodore say you should not use sprites anyway so as to be compatible with their new hardw are which is rumoured to run WindowsNT, yipeee. By then we will be hopefully shipping the Jaguar lib for Blitz.

there is some example in one of the bum's

[earok]

I think you can get away with nudging the display a little to the right (though maybe this'll put it in the overscan area? Not totally sure)

Statement ResizeWidth{clist.l,amount.l,xadjust.l}

diwstrt.l = xadjust*8
diwstop.l = diwstrt + amount*8

dUfstrt.l = Int(diwstrt/2)
dUfstop.l = Int(diwstop/2)

DisplayAdjust clist,amount,dUfstrt,dUfstop,diwstrt,diwstop

End Statement

Try something like ResizeWidth{copperlistid,0,2}.

[carrion]

Gents
Sorry for digging out old thread but I've encountered the related issue.
In my case I only scroll up and down and I want to use DisplayBitmap for this. Scrolling up and down IMO doesn't need setting up scroll for side scroll.
When I setup InitCopList with $15 (I have 5 bitplanes) id shrinks the screen on sides.
My question is there a trick to scroll up/down without setting up copper list with scrolling param $15?

[carrion]

Bump.
My goal is to have scrolled up/down bitmap and 7 or even eight sprites.

So let me rephrase the question:
Is there a way to scroll a bitmap up and down without using DisplayBitmap or without setting the scroll bit in InitCopList?

Maybe changing the pointer of the bitmap? But I don't know where and how to do it.

[Photon]

Vertical scrolling only shouldn't affect the visible width of display, and therefore not the number of usable sprites, unless the width is overscan. Even in the case of only vertical scrolling, you must put a scroll value of 0 for both playfields. It may be wrongly initialized by some other code or Copper list, like the Workbench or the previous program you ran.

This is from the HW, I don't know if languages coerce a software scrolling flag into 8-way or no way.

From reading the thread it looks like you can control the HW registers, so it should definitely be possible.

It's only horizontal scrolling that removes a sprite on OCS/ECS (and potentially more on AGA depending on FMODE).