MSX2 - 8 ways smooth scrolling SCREEN 5

In my old program I used adjust register for both h and v scrolling.
In new program I used adjust register for h, line offset register for v.
It can help to switch direction with no delay.

copy 1/16th to back buffer from left to right for scroll right
copy 1/16th to back buffer from right to left for scroll left
no need to reduce any height, lost only 16 pixels for horizontal scrolling
It fast enough for draw 5-10 software sprite at 16x16 or 32x32 from my testing
because each scroll need to draw a little line about 1-2 / 16 of the screen.
hardware sprite is easy to apply by relocation all sprites every scrolling. (use sprite in page 2)

I used HMMM of V9938 for optimized and it can optimize to faster than this.
(Sorry for my english, I can read english because I read "Daewoo CPC300 MSX2 User Manual" for 20+ time)

Mmh, actually that is 2784 bytes per interrupt (5568 pixels)… Sounds like quite some room left…

I wonder why I had such problems. Need to dig up my old code I guess :).

amazing information

Some ideas:

• You don't have to restore backgrounds first for areas where a solid sprite part will be drawn. Many sprites have large solid parts, see e.g. Core Dump that uses this technique.
• Sprites will often only move 1 or 2 px in a direction each interrupt so only a fraction of a 16×16 area has to be restored, unless again you have very transparent sprites.
• No need to 'back up', all parts can be restored by HMMM from your page containing all tiles, or even by YMMM from a corresponding tile in the same or the alternate swap page in at least 50% of cases, often more.
• Depending on the level design, a great part of the screen might also be restored by a fill command (not in this particular demo with more elaborate tiles, but certainly in a MegaMan or Mario-kind of levels).
• Again, depending on the surrounding background, you might be able to move the entire sprite by one copy command including a slice of its homogeneous background. That eliminates all separate restoring by issuing one copy command of e.g. 18×16 px for horizontal movement.
• Much of the background shouldn't need wholesale copying by 16px if you have many repeating tiles, which is the case in a vast majority of games. This take a lot of VDP burden away (by adding some CPU burden).

This all will require some checks for each copy instruction. But comparing games such as Blade Lords or Core Dump, it seems you can achieve quite high frame rates with these tricks.

I'd love to see demos of both. Combining (relatively) smooth scrolling and many characters could give an awesome game, even at 30 fps. Many blocky scrollers on MSX had much lower frame rates than 30fps and were deemed acceptable.

@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