MSX2 - 8 ways smooth scrolling SCREEN 5

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

Por Grauw

Ascended (10560)

Imagen del Grauw

19-03-2014, 17:09

Hrothgar wrote:
Grauw wrote:

(Btw, note that tile-based animations need to be rendered twice, once to the foreground and once to the back buffer.)

Hardly, the animated tile in the back buffer only needs updating if
1) it is imminent to be flipped into view AND
2) its current state isn't an acceptable transition from the alternate page that is about to be flipped out of view.

That’s true, but…

Quote:

Knowing the copy burden and thus the available space for X animation transitions in advance can even allow you to plan to *avoid* having to update the back buffer tile during page flip.

…to me this seems to be very very hard to predict and plan for.

Because we don’t want to get a worst case scenario where a whole bunch of tiles need to be updated in the back buffer when we need to page flip. After all, at all times we’ve got to stay within 1/60th of a second. If there are let’s say 10 animating tiles, we could already be in trouble changing all of them at once.

I think it’s much simpler to just update the tile on both the front and the back buffer. As long as these animations are slow ones (let’s say, 1 - 4 fps) I think the load is low enough that we don’t need to try and optimise it. Also the optimisation will get less effective once the animation gets more than 2 frames. E.g. with 8 frames, only a 1 in 8 chance that it gets through. And for the fast animations we can just use the software sprites approach.

Por slumpmax

Rookie (26)

Imagen del slumpmax

19-03-2014, 17:54

Did I miss something here?

Por Grauw

Ascended (10560)

Imagen del Grauw

19-03-2014, 17:56

Just ignore pages 3 and 4, unless you have a fancy for drama Smile.

Por PingPong

Prophet (3885)

Imagen del PingPong

19-03-2014, 18:58

GuyveR800 wrote:

@Hrothgar
At some point you're spending so much CPU time on optimizing the screen rendering, you're gonna need an R800 to actually manage a somewhat demanding game. And then you realise V9958 has hardware scrolling and you go lol

Ah Ah Ah ;-)

Por anonymous

incognito ergo sum (116)

Imagen del anonymous

20-03-2014, 08:14

just to return on the subject, few years ago I did some tests of smooth scrolling in screen 5 and screen 8 on msx2

https://sites.google.com/site/testmsx/Home/smooth-horizontal...

Basically I had almost a brute force approach coping a slice 16x160 at time from front buffer to back buffer.
The tricky part was to build "on fly" borders and incoming screen area: this part was demanded to the z80
In this way all HW sprites stay available for the game and z80 and vdp go in parallel.

The result goes at 60fps with plenty of free time for game logic.

Por slumpmax

Rookie (26)

Imagen del slumpmax

21-03-2014, 16:06

I saw your test before I wrote this topic.
MSX Community makes me feel that even a different hemisphere, but there are similar ideas.
I wrote this topic to confirm that.

Por Grauw

Ascended (10560)

Imagen del Grauw

21-03-2014, 16:11

I’ll see if I can find and make a video of my old code Smile

Por DarkSchneider

Paladin (942)

Imagen del DarkSchneider

14-04-2014, 10:58

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.

I have some questions that I don't understand:

- 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).

- Vertical scrolling. I searched but not found a clear answer. Everyone say to use r#23, but this is vertical offset. Then we have a real 256px height buffer on each page, so we can draw offscreen and offset to show. But what about when we get out of that range?. After reading other posts, the only conclusion I have got is using the line interrupt to change r#23 on the fly for that line. But I don't really understand the method and how it works, maybe someone could explain me.
EDIT: maybe I think how it works, please correct me as needed. R#23 is full 8-bit so its values can go 0-255, then you simply construct the "next-line" and when bottom is reached, continue on 0, then simply add to r#23 because when exceed 255 it returns to 0 and start again.

Por Wolverine_nl

Paragon (1159)

Imagen del Wolverine_nl

14-04-2014, 11:17

I am busy with a vertical scrolling thing atm, will be checking in lateron in this topic, I am doing it in MSX-C, but all regs and such apply the same in it.
My plan is to not use the full screen for the scroll, right side is for stats, should this make the scroll even smoother?

Por DarkSchneider

Paladin (942)

Imagen del DarkSchneider

14-04-2014, 11:31

I think you have to use top or bottom for the stats, because the use of line interrupt to draw stats or gameplay screen. If you use a side you can't use them.

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