Quote:

You MUST split the copy in blocks whose dimensions allows and execution time lower than a frame period.

hmmmmm....
Right now I have my copies outside of the interrupt...
And the copies are the only thing outside of the interrupt.
I thought this might be a good idea to make sure that not every level scrolls at the same
speed.
I want slow and fast levels.

And putting the copies outside of the interrupt makes it that the game
(movement characters etc.) work on an allways constant speed,
and the background scroll doesn't have to be allways on the same speed.
I do synchronise the hor.sc.offset with the copies, meaning that whenever a
1/8 part of the screen is copied, the hor. offset changes 1 pixels to the left.

So the screen is build up in 8 steps (which can be on 1 or more frames per step
depending the size of the copies)

But the speed of the game will allways be constant......

If I make bigger copies than the execution of 1 frameperiod the game keeps on
going, but the scrolling will be slower.

Is this not the ideal way to play with the speed of the copies independantly of the
speed of the game?????

Why only 8 steps?
You can have 16 hiorizontal positions with reg19, this means twice
the time for your copyes before the need of a pageswap.

Yeah, use all the 16 steps and have a 2 pixel at a time scroll. That will be the maximum speed
you can get. If you wanna go faster than that you need to combine some repative tile techniques
(like the SD-Snatcher scroll) with the 'regular' scroll.

Good point!

I started using 8 steps because I wanted to use the border blanking method used
in spacemanbow.
This masks the left and right 8 vertical lines.
If I would use 16 steps then this method would be unusefull.

It's either:

16 steps and using sprites to camouflage the edges
16 steps and black lines to camouflage the jumping at the edges

or

8 steps and using the masking register
8 steps and using black lines to camouflage the jumping at the edges (only 2+ & tR)
8 steps and using black sprites to camouflage the edges

I know the masking register is only available for 2+ and TurboR.......
Making a choice still is difficult.

I made the choice to use 8 steps, I'll work with it for a while,
and maybe later choose 16 steps.....

Unless someone tells me that I have to use 16 steps RIGHT NOW !!!!!!

when using 16 steps and u mask the edges manually by pasting black lines
and parts of the new background, how does this look regarding the sprites which
leave the screen.

Because you will see sprites on top of the black end of screen.

(o.k. you could use 1 sprite to mask each sprite leaving screen.......)

O.k. While Im at it.....

How difficult is it gonna be using a screensplit halfway the screen so I can use 64 sprites.
Because using all 16 steps (read post above) will require extra sprites for masking the
borders....

This masking is not making me happy, because the ship I'm using is 2 sprites,
the ship can shoot 3 bullets (total=5 sprites)
If I mask the borders with sprites left and right, then you allready have
7 sprites on 1 horizontal line when the ship shoots 3 bullets.
This is not making me a happy camper....
Because then only 1 enemy (of 2 sprites) can be on the same line as the ship...

Only 1, because no more then 9 sprites can be on a horizontal line.......

now because of THIS masking the edges with sprites doesn't SEEM an option....

Thats why I choose masking the edges with the MASKing bit (2+ and turboR).
Meaning that on a normal msx you will see the edges "jump" like spacemanbow,
but on a 2+ or tR it will look good.

what should I do?

The solution is ready (the one I am implementing in Total Parody)

Use the VDP for masking borders and sprites for masking sprites

you need a masking sprite only when the enimy is entering the screen and crosses the border
and you can remove it as soon as the enimy as entered the screen

the problem is that you need to update the coordinates of masking sprites
accordingly to where each enimy enter in the screen, but this is the best
solution in terms of final result

2 sprite your ship
3 bullets
2 enimies
1 masking sprite (only if and when required: it can become an extra enimy
while none is crossing the border)

Total
8 sprites

Please
Use 16 steps...

There is always the trick of shooting the bullets on different heights. So you can shoot
6 bullets with having only 3 sprites in a row.
Maby you have enough time for one software sprite. If you copy the ship
within the VBLANK period (and recover the background first offcourse) it will be without
blinking (it would take about same amount off time as five 16x16 HMMM copies).
Takes some need of keeping track on scroll copies but stil one should be quite doable.

Obout that software sprite... probably not an option now i really think about it.
At least not if you go for the 8-steps scroll or 16-step 2 pixel scroll.

O well use V9990 all problems solved .

The masking register for 16 pixels as well. As long as you draw the new patterns each 8 pixels.

Doing a sprite split is easy. Doing it is such a way that it is invisible is really difficult.

Just keep the sprites on the endge (splitline) double in both SPATs on same sprite number,
and do not forget that a sprite split does not mean 64 usable sprites (more like 48±).

ehmm....
as far as I understand the problem is the number of sprites on the same line
not only the whole number of sprite on the screen

My solution leads to
1) minumim number of used sprites on the screen
2) maximum number of useful objects on the same line

Spritesplit:

I keep my ship, 2 options, 1 missile and 9 bullets the same above and below the split.
So 2+2+1+9=14 sprites remain the same above and below the split.

When I make the split at for instance y=100 should I suppose I wait until the start of HBLANK???? right??

And as soon as that starts I load my new spritetables (exept the ship, 2 options, 1 missile and 9 bullets) into VRAM, And the colorsettings, and the possitions.

This is what the spritesplit comes down to, right?


Ps. thanx for the tips given above.
And YES, I'm gonna use 16 steps and 1 sprite for masking the incoming/outgoing sprites and I'm gonna mask the borders with the VDP (copy past little black lines)

About putting the background scroll inside or outside the interrupt as I mentioned before.

What can you advise about this.... The thing is, I want to have as much freedom as possible with the speed of the backgr.scroll. I would love to have slow and fast scrolling levels.???

Quote:

The solution is ready (the one I am implementing in Total Parody) Use the VDP for masking borders and sprites for masking sprites you need a masking sprite only when the enimy is entering the screen and crosses the border

how many sprites would you advise to use for the masking?
would 1 be sufficient? (hmmmm, maybe this is a bit personal)