yes,
but with only the main layer.
The second layer is updated each 16 frames,
so it can scroll faster but not smoothly
actually if you move the second layer of two
points per update the result is still good.

Note that the main layer pass on the top
of the second layer.

hm.. this 1/16 update for the background is what makes it unrealistic then I guess, the 1/16 movement looks a bit odd, and you don't really get the idea of 'depth' in the whole picture.

I rather have no multilayer at all then I think.. If you get rid of the 2nd layer, and only copy the full 'first layer' around, with a speed-boost, do you gain any performance then for games?

a little calculation.. 24lines copy per int, 8 scroll steps (we're here for faster movement eh, so we scroll with steps of 2), 8*24 is 192 lines per 8 ints, so per scroll-cycle.

Seems fair enough..

Yes, fair enough for a horizontal scroll with a direct response to left or right, but not for a
all directional scroll.

Quote:

Yes, fair enough for a horizontal scroll with a direct response to left or right, but not for a all directional scroll.

Adding a vertical component to the scroll is as easy as fiddling with VDP(24)

Look at my calculation:
assume a screen 240x192 + 16x192 for border masking

minimum speed:
16x192 columns + 1x192 + 1x192 per int, per 16 scroll steps => you get 240x 192 columns each 16 steps masks for borders included

double speed
32x192 columns per int + 2x192 + 2x192 per int, per 8 scroll steps => you get 240x 192 columns each 16 steps masks for borders included

ok, I saw it, (used bluemsx)

I guess a multilayer/multidirectional scroll in screen 5 is not really possible.....

Quote:

The second layer is updated each 16 frames, so it can scroll faster but not smoothly

indeed this does not give a convincing feeling that there is a second scroll going on.

If using only 1 direction (horizontally) then is it possible to create smooth scrolls using a couple of screen splits... and make layers on top of each other with different types of scrolls???

Moreover, if a scroll is made with (lets say) 4 screensplit (so you have 5 gameparts which each scroll with a different speed), what problems will arise??? (sprite positioning???, vdp problems??)

@Aurora: I still have my doubts it is just that easy. To start with the screen height, this
got to be redused to, what i think is easiest, 144 lines (considering 16x24 tilesize). This way
only 7 (since two are probably half visable) of 8 'bars' are visable and so the one left can be
used for updating. Wich, in means of a vertical scroll, needs to be done on both pages, so
twice as much but still in 8 steps so... could be possible?

Note: still talking about direct response and not like the famous Total Parodie scroll once in a
while a direction change.

@norakomi
screen split is critical for sprites!
you cannot have a sprite that passes the border
among the different splits!

@GhostwriterP
My scroll is almost real time, you need 16 frames in
order to change direction, and works in 8 directions.
This is not very critical if your main character can move
in the screen.

@norakomi: Sprites will deffinitely become a problem since they are also affected by the
adjust register.

@norakomi
In my TP I do pageswap each 16 farmes,
the main layer moves 16 steps in 16 frames
the second layer moves 15 steps in 16 frames

you could have an acceptable result having
the second layer that moves 14 steps in 16 frames
but you loose part of the smoothness

if you want layers that move slower than mine you
have to do pageswap each 8 frames,
in this case you can have:
the main layer moves 8 steps in 8 frames
the second layer moves 7 steps in 8 frames
(this gives you the max smoothness giving a result equivalent to 14 steps in 16 frames)
or else you can have that the second layer moves 6 steps in 8 frames

This is visually acceptable and results in a slip of 4 points each 16 frames

Your problem is that in order to do pageswap each 8 frames
you cannot use double pass and TPSET, so the layers cannot
really overlap (like mines) and the effect is blocky unless you
do not use color tricks.

Artrag: How about having the second layer being still (not scrolling at all) ? Perhaps the result would be even better, if you concider making the background graphics appropriately (read far distance from the front later).

@Maggoo
sadly, in scr5 it is impossible, this means that, at each scroll step, you need a swap page!!

nevertheless, in scr4, this is feasible and very nice.

@Artrag: Well you use animated tiles... so that is a pro... but I still prefer the sort of
'16-bit' feel as you might say.

Quote:

@Maggoo sadly, in scr5 it is impossible, this means that, at each scroll step, you need a swap page!! nevertheless, in scr4, this is feasible and very nice.

Oh yeah, I forgot. Actually I think your routine would be a perfect fit for a RPG, using only one layer of scroll but having animations (water, wind in trees, ...). What do you think ?

@GhostwriterP
If you refer to the use of sc4, keep in mind that if the use of animated tiles allows any
kind of speed for the sencond layer, you must take into account that:
1) you cannot have real overlap between layers (no TPSET
means blocky boundaries in the main layer)
2) you cannot have border masking unless you do not
use precious sprites!!