Quote:

I want to make a full directional scroll. So, I guess, R#2 is no option then?? What if i have the map data in page 2 (screen 5) the pointer is in (0,0) then at vblank I 1) switch to screen 5 2) copy (0,0)-(32,24),2 to (0,0),0 ;this means copy the map screen the pointer points to, to the map screen of screen 4 currently being displayed. 3) switch back to screen 4 Then when the character moves right, the next frame I: 1) switch to screen 5 2) copy (2,0)-(34,24),2 to (0,0),0 ;this means copy the map screen the pointer points to, to the map..... 3) switch back to screen 4 Then when the character moves down, the next frame I: 1) switch to screen 5 2) copy (2,2)-(34,26),2 to (0,0),0 ;this means copy the map screen the pointer points to, to the map ..... 3) switch back to screen 4 This is my thought. But how do I really realise this for real !???

In short: don't. The nice thing about SM2 was that it was Screen5. Screen5 just looks that much better than Screen4 does, even if you're a good pixel-artist. Stick with Screen5 for the main game, perhaps Screen4 could be used for the odd 'end boss' and such, maybe one or two levels that scroll so fast you won't have time to notice any crappy gfx

As to your questions; I'd recommend not using commands for the 'copies', since you most likely won't need the extra speed anyhow. Usually it doesn't warrant the extra trouble of the mode-split and planning. Regarding scrolling; it pretty much works the same way as it would in Screen5. You 'set adjust' your way trough till you've reached an 8 pixel block, and then you update the 'map' to reflect the changes while setting the X adjust to 0 again. Vertically works the same way, only here you'd use VDP23. The downside of Screen4 is that it won't be easy (hard, even) to mask the left and right sides of the screen, especially when you need your sprites for other stuff.

Assume for example that you need 8 direction scrolling and variable X-Y speed (I undeline variable X speed)

Scr4 is the only way to get this effect

Given you need scr4, there is no reason for not using VDP copy at vblank.
The vram is already there and, even if the algorithm is complex, the code
is there, ready to be used.

I do agree, scr4 gfx is very bad (wrt scr5), but remember dragon's lair demo,
you can still get surprised by what the tile modes can do when you have a
large storage (112KB of free ram, in this case) and you can change the palette
and the pattern definitions.

BTW, a completely different way to exploit the VDP in scr4 is to use copies to modify
the tile patterns and colors directly in VRAM

Also in this case you have up to 112KB free to store the tile pattern animations.
And if you do not want to store 112KB of precomputed animations (and why not)
it is easy to imagine the use of fast copy to have vertical animations of set of tiles,
(like a ladder that moves upward, or a rotating column).

Moreover you can also use TPSET, OR or XOR to get spacial animated patterns.

It is only a matter of imagination and artistic talent.

Think to an endboss where its tiles are redefined realtime from a 112KB vram
You could have smooth animations for its movements with hundreds of frames
based on tiles dynamically defined

Quote:

As to your questions; I'd recommend not using commands for the 'copies', since you most likely won't need the extra speed anyhow. Usually it doesn't warrant the extra trouble of the mode-split and planning. Regarding scrolling; it pretty much works the same way as it would in Screen5. You 'set adjust' your way trough till you've reached an 8 pixel block, and then you update the 'map' to reflect the changes while setting the X adjust to 0 again. Vertically works the same way, only here you'd use VDP23. The downside of Screen4 is that it won't be easy (hard, even) to mask the left and right sides of the screen, especially when you need your sprites for other stuff.

Ok, here's my complete plan:

I want to have an onmi-directional 2 layer scroll.
& DONT want to use r#18 or r#23
I want the first layer (BACKGROUND) to scroll with 8 pixels every other frame
and the second layer (FOREGROUND) with 8 pixels EVERY frame.
So the scroll will go very very very fast, and omnidirectional.

Meaning that every frame I would have to do a normal 32x24 pixel copy for the background AND a TPSET 32x24 pixel copy for the foreground (On top of the background).

This must be possible. Dont say NO right away. Help me think about this.
I would like to talk about this idea and then make a plan how to get it to work.

Again:
I dont know screen 4, so learning screen 4, making this plan, AND implying this multi-layer scroll will take me at least a month (probably more !)

What do you think guys ?

It seems absolutely doable !

Few questions about the effect you want in order to understand how to proceed

1) describe the background, does it have some modularity (i.e. a repeated large pattern NxM) or it has a unique map
2) decribe the foregound, is it composd in mainly by horizontal structures (e.g. like in platforms))?
3) what % of the screen do you expect be filled by the foregrond?
4) do you plan to store both foregound & background as byte maps in VRAM ?

Quote:

I want to have an onmi-directional 2 layer scroll. & DONT want to use r#18 or r#23 I want the first layer (BACKGROUND) to scroll with 8 pixels every other frame and the second layer (FOREGROUND) with 8 pixels EVERY frame. So the scroll will go very very very fast, and omnidirectional. Meaning that every frame I would have to do a normal 32x24 pixel copy for the background AND a TPSET 32x24 pixel copy for the foreground (On top of the background).

Very fast indeed. Wondering how it's usable. Anyway, I'm not so sure whether it can actually be done at those speeds. To (t)pset copy a screen from a larger level takes two commands per line. 48 for a full screen. I don't know if you can actually get that done inside the vblank. I have a feeling it's going to take a lot more. But you'll have to test it to be sure.

Building it directly from RAM is doable, but it will take the better part of the frame time to display it. Leaving you with little cycles to do anything else.

I do not agree

To copy a screen from a larger level takes only 4-8 VDP commands for the whole screen (32x24)

If you take both background & foreground by VRAM maps, all you need 4-8 commands in fast
copy (background) and 4-8 commands in tpset (foreground)

The vblank a @50Hz should be fine even if I didn't measures in this situation when I did the VTEST

norakomi, about the two layer scrolling, consider also this:

In 128K of VRAM you can store more than 8 complete tilesets, (you have 8 pages,
but the room needed is only 12K or 6+2=8K, so you could have up to 10-16 "pages"
for tiles).

Assume you want to slowdown the background:

You could use for the background a specific sub set of tiles, let say the first 96 patterns of the 256 available.

You redefine the background tiles in 8 ways (less if you want it move faster) in order to simulate
its fine movemet. For X scroll you could have 8 X positions.
This is very doable if the background is a large, repeated, pattern, like rocks in a
cave or the skyline of buildings agains the stars in the night.

You store the new pattern set in the 8 pages, where only the first 96 positions change.

Now you can scroll the background independently by the foreground by simply setting the
R#3,R#4 and R#10, cyclyng among the tilesets.

This is a "zero cpu" backgroud scrolling.

In this case you cannot use my technique to update the screen using the VDP, as the VRAM is full,
nevertheless, you can use a different solution to expliot VDP commands.

The vdp can be used with fast copy to move the whole screen on itself (quick and dirty,
you need only one command)
In case of X scroll, move +/- 1 the screen, in case of vertical scroll, move +/- 32 the screen.

This allows both X&Y scroll, but the z80 must be incharged to fill the new
extra line that enter rigth/left (forX scroll) or up/down (for Y scroll)

The gain is in any case HUGE

compare 768 OUTs against

32+2 OUTs for Y scroll
3*24=72 OUTs for X scroll

Quote:

To copy a screen from a larger level takes only 4-8 VDP commands for the whole screen (32x24)

True, in screen 5 the screen would cover 6 lines. So you could copy every fourth line in a single copy. You'd have to split your level data in 4 parts as well and the level couldn't be more than 4 screens wide as it has to fit into a single screen width. Although you could work around that by having multiple overlapping 4 screen wide sections.

Quote:

Now you can scroll the background independently by the foreground by simply setting the R#3,R#4 and R#10, cyclyng among the tilesets. This is a "zero cpu" backgroud scrolling.

Fantastic. Does this work for vertical scroll as well ??

Quote:

Few questions about the effect you want in order to understand how to proceed 1) describe the background, does it have some modularity (i.e. a repeated large pattern NxM) or it has a unique map 2) decribe the foregound, is it composd in mainly by horizontal structures (e.g. like in platforms))? 3) what % of the screen do you expect be filled by the foregrond? 4) do you plan to store both foregound & background as byte maps in VRAM ?.

1. a unique map
2. yes only horizontal structures, no curves
3. 10%, 20% maybe a bit more
4. yes, that seems most logic if we're thinking about doing the fastcopy and the TPSET copy

Quote:

True, in screen 5 the screen would cover 6 lines. So you could copy every fourth line in a single copy. You'd have to split your level data in 4 parts as well and the level couldn't be more than 4 screens wide as it has to fit into a single screen width. Although you could work around that by having multiple overlapping 4 screen wide sections.

Exactly, you can split the level in stripes 128xheight where the last screen on the right
overlaps to the first screen on the left of the next stripe.

this is what i was meaning when i sayd

Quote:

BTW, in the case of a "shooter" scroll probably something could be done to overcame to the 128-256 width limitation, for exapmte by putting in VRAM the level divided in strips of 128 X heigth, where the last 32 X heigth part is copied also at the beginning of the next strip.

Edwin, if you limit the scrolling to the horizontal direction you need always 4 copyes,
but, the magic in VTEST is in the Y scrolling, that is not at all trivial.

The algorithm is complex, but once understood, very easy to be implemented
and the cost vary among 4-8 copies depending on the result of (Y mod 24)

Quote:

Fantastic. Does this work for vertical scroll as well ??

Well depends on the scroll speed and smoothness.
Assume you have the room for 8 tilesets,
you could draw, for each background tile, 4 frames for X scroll and 4 frames for Y scroll.

So you have 4 possible steps in horizontal and 4 possible steps vertically.

Actually, for a full 8 direction scroll, you would need 4x4 = 16 tilesets considering all the X/Y steps of the tiles

In any case this is non necessary if you have only horizontal or vertical movements.
The sole problem that I see, is that you cannot change direction in the middle of a movement
but you need to reach a given position among the 4 in order to pass to a different direction.

Quote:

Few questions about the effect you want in order to understand how to proceed 1) describe the background, does it have some modularity (i.e. a repeated large pattern NxM) or it has a unique map 2) decribe the foregound, is it composd in mainly by horizontal structures (e.g. like in platforms))? 3) what % of the screen do you expect be filled by the foregrond? 4) do you plan to store both foregound & background as byte maps in VRAM ?. 1. a unique map 2. yes only horizontal structures, no curves 3. 10%, 20% maybe a bit more 4. yes, that seems most logic if we're thinking about doing the fastcopy and the TPSET copy

1) actually this makes things harder and the probably the dynamic definition of the tiles described above isn't the best candidate, a VTEST like approach could be better

2) in this case we could evaluate the possibility to use a mix of fast copy and tpset also for the foreground, horizontal structures can be moved without TPSET

3) this helps a lot in using fast copy for the foreground!!

4) this is the sole way to use the VDP

Quote:

So you have 4 possible steps in horizontal and 4 possible steps vertically. Actually, for a full 8 direction scroll, you would need 4x4 = 16 tilesets considering all the X/Y steps of the tiles In any case this is non necessary if you have only horizontal or vertical movements. The sole problem that I see, is that you cannot change direction in the middle of a movement but you need to reach a given position among the 4 in order to pass to a different direction.

Thats why I want to move with steps of 8 pixels at a time (thats incredibly fast).
This is easier to implement I guess, but the end (the borders) of the map will be reached very quickly.

Apart from drawing a lot of tiles the solution with dynamic tilesets is the easiest
and allows you lower speeds, but, IMHO, it works well only for repeated patterns

assume a 4X2 pattern for sake of simplicity anf the sole Y scroll

ABCD
EFGH

you need 4 positions where A move upwards,
E move upwards and enters in A,
the part of A that goes out of the pattern is set in A.
the same for B and F, C and G, D and H.

Quote:

the part of A that goes out of the pattern is set in A.

in E ?
I think I understand a bit of what you're trying to say.
But its difficult for me to visualise.

sorry you are right, it was a typo,
the part of A that goes out of the
pattern is set in E.