# MSX2 - 8 ways smooth scrolling SCREEN 5

Página 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8

okay, thanks for the advice, will not even attempt it then, waste of time

I am pretty new to the scrolling thing, so getting it right will take some time, I tried it 2 years ago, I got the screen to scroll vertically, but things happen in life that you have to put things aside, MSX and such in this case, so starting over again with new energy.

i saw the youtube film of the original poster, looks cool, going in all directions. Getting great ideas for RPG's
But time and daily jobs isnt always a friend.

DarkSchneider wrote:

If wide copy is faster than narrow ones, why don't you copy the optimal block? Instead 16x212 blocks, you could copy the central-width 224x16 blocks to the back buffer.

Yup.

DarkSchneider wrote:

- You say that have 16 frames until next swap buffer. But that should be on a predictable scroll direction. So let use a [-8,7] range in R#18 values for easier, you start at offset -8 and each frame you copy 1/16 and add 1 to r#18. But in a unpredictable scroll direction enviroment, you really have 8 frames, you can move to left or right, so you have to start in r#18 position 0 not in an edge. Also you can begin to walk to right at at any moment change to left. This is, unpredictable scoll direction. For that, you should construct the back buffer on a 8-offset basis instead 16, using the value H-r#18 (H for horizontal) so if <0 (in the previos -8 to 7 scale) you start to construct a -8 offset back buffer, and if >=0 you construct a +8 offset backbuffer (or it was 9?, have not thought much on this).

I don’t fully understand but I never did such a complicated thing. In my scroll, direction was unpredictable, but I had all 16 frames. I could start r#18 at any position. If you start all the way to the left simply make sure the back buffer is pre-set up with the correct content so that you can switch page on the next scroll if needed.

DarkSchneider wrote:

- Vertical scrolling. I searched but not found a clear answer. Everyone say to use r#23, but this is vertical offset.

It’s not a true memory offset, the VDP always stays within the same page and it wraps around at line 256. You draw the new graphics in the vertical blanking area, not on a different page.

Quote:

I don’t fully understand but I never did such a complicated thing. In my scroll, direction was unpredictable, but I had all 16 frames. I could start r#18 at any position. If you start all the way to the left simply make sure the back buffer is pre-set up with the correct content so that you can switch page on the next scroll if needed.

Ah well, understood. So you use an initial r#18 value with its pre-made back buffer. The easiest is the one you mentioned, full left, more intuitive.

So if you start moving left, change to back buffer and rewrite the first 1/16th of the back buffer (the old front one), if you move left again rewrite the second 1/16th, but if you move right instead left, you only need to rewrite the first 1/16th with the correct data, because the other part of the buffer has correct data because it has not been written yet.

This is simple H & V scroll sample in MSX2 BASIC

The Artrag technique for the horizontal scroll on MSX2, is the best I saw on SC5 and SC8, the smoother, the less CPU consuming, no Sprite waste to mask the border shaking...

Now, MSX2 can be much powerfull than AtariST, because the ST do not have SETADJUST or HW sprites.

slumpmax wrote:

I got idea for sprite.

does not back up but draw pattern background directly to it's position before redraw it.

the problem with that is that the sprite can't be aligned to a pattern, it can be over up to four patterns. So finally is wasted more time.

GuyveR800 wrote:

In my opinion it was a good question to ask, because Hrothgar is saying "easily" and "easy" a lot. One would expect that would be based in some kind of programming experience or insight...
A lot of those "easy" things are not trivial at all.

But I guess it's a no-no to question things.

This being the MSX Hostility Center...

right, new developers tend to think that vdp access or its speed is the only one botleneck, so, starts with ideas, lets make all precalculated in Z80/RAM and then make few vdp accesses per frame as possible.

But not, precalculating, like, looking for background pixels that won't be uncover in the next frame, that takes a lot of z80 time!, just looking in the pattern and the future movement step, and making a mask patterns that points out only pixels that will be uncover, that is a lot of time!...

By example, for one 32x32 sprite, IT IS A LOOP of 32x32 = 1024 runs!. And it is a run where it shifts patterns bits or nibbles!, or in the BEST case of SCREEN 8, you will be wasting RAM 1024 bytes for just a 32x32 sprite. Runs, a read of all that 1024 bytes looking for the MAGIC color that tells = transparent. Minimun is like 5 or 6 instructions in the inner dot loop.

Is to say 6000 + looping code + precalculating the math for start address and the new offset address taking in account the movement, it is like 8000 instructions? per sprites, you to CREATE the pattern of uncover pixels on the next movement / pattern change (animation).

Some ppl, thinks, it is a 3.57mhz CPU it is a lot of ticks...., no it is not, because the average instruction takes like 7 ticks, and then we needs to divide it by 50 or 60 frames. So do the math, you have ONLY 10200 average z80 instructions per frame!.

And you needs to do , logic behaviour, video , sound, mapping, animation....

Best games, are mostly done with look up tables, precalculating all and BURNed it in ROM!. A technique that in todays PC WORLD is not used and that is why PC games with kick ass hardware is sometimes slow!.

I think ARTRAG’s approach is nice though. It’s a good trade-off if you don’t want to sacrifice hardware sprites, which you probably want because the VDP doesn’t have much oomph left for software sprites. Also hardware sprites need less CPU time so you should be able to make do with a little less of it.

I was also thinking, if you need both sprites and CPU time, this copying / clearing of a line, it could also be done with a VDP command. CPU access to the VDP slows down command speed as well, after all, so removing the CPU from the equation also speeds up the VDP command execution a little. However the VDP isn’t very efficient with vertical commands, so it won’t be very fast. Nevertheless, if this can be done at 60fps (big question mark ), it will free up that CPU time. Again, a trade-off you can make depending on what’s more important for your game.

Grauw, border masking is done by vdp and cpu in parallel in a small fraction of time of the vblank.
This works also in screen 8.