Horizontal/vertical scrolling is not hard on msx2, many people have shown that.
However creating a full game (designing /graphics/music) is timeconsuming and takes dedication/motivation, and me personally I feel I always lack either time or motivation. I think this is why ppl like to discuss about possibilities, but dont really bother to create something themselves (other than small tech demos)
Btw grauw I assumed your RPG demo during the fair was v9958, but I realize it might have been v9938. If the latter was the case, my dissapointment about the diagonal scroll not being smooth was a bit misplaced 
Hahaha maybe, I'm still "young-ish" though with my 33 years old hahaha
MSX is about 35 years old and still very alive, despite the doctors declaring it officially dead multiple times. So, maybe, just maybe - we're not that old, either.
Horizontal/vertical scrolling is not hard on msx2, many people have shown that.
Btw grauw I assumed your RPG demo during the fair was v9958, but I realize it might have been v9938. If the latter was the case, my dissapointment about the diagonal scroll not being smooth was a bit misplaced
Smooth horizontal scrolling on MSX2 (V9938) with 2px / frame at 60 Hz, full-screen, with sprites, is impossible. Reducing the play area to 256x160 (minus 16x16 pixels of margin) might just be able to work, but it’s extremely tight. A good way to waste a lot of time making a tech demo rather than making a game… My game in progress is for MSX2+ (V9958), because it gives breathing room to scroll at higher speeds and do things like tile animations and particle effects with sprites.
On MSX2, I would say the workable options are:
- 8 pixel non-smooth scroll in screen 5 / 7 / 8
- 1 pixel / 60 Hz frame scroll in screen 5
- Arbitrary speed scroll in screen 4
Each has their advantages and limitations.
About why the diagonal scroll wasn’t smooth on my MSX2+ game in progress I showed at Nijmegen;
Currently I spend 50% of the CPU time on updating the full sprite colour table every frame. This is needed when all sprites change priority, and with a solid 60 fps timing budget (59659 CPU cycles/frame) I need to assume the worst case. Add to that 25% of CPU time for scrolling two pixels in one direction, and it goes just over budget when moving diagonally.
Now the CPU time spent can be optimised, e.g. time spent on scrolling can be reduced to about 10-15% I think. Since I scroll on a single page, this leaves just a small 8x212 masked strip on the side. Currently I do eight 4x16 HMMM copies every frame. Instead, I can do a single 2x256 HMMC fed straight from RAM by the CPU (270 OUTIs = 4860 cycles). Alternatively I could use 2 pages for scrolling, needing just 1-2 16x16 HMMM copies / frame, but it consumes a lot more VRAM, so I’m still undecided.
But my real grand plan to free up CPU time is to make the game run at 30 fps, while updating all the motion at 60 fps (scroll + sprite positions). This means the input handling, game logic, collision detection, tile animations, sprite animations and z-sorting, all this expensive stuff gets spread out over two display frames. This will give a lot more breathing room, and since the motion updates at a higher frequency, the game will still appear smooth.
Maybe this idea is also useful for others attempting a similar thing. I think it’s pretty nice at least. Obviously both of these changes require quite significant rewrites, so I hope it’s ok that I showed you something at Nijmegen rather than nothing .
Also I’m very conscious about the time I spend on everything… Already on the current scroll code I spent significantly more effort than I planned, only to throw it away. That’s the life of a programmer I guess, but I do want to finish this, so I need to be careful to keep the scope down and make smart choices about what I work on. I have high standards and do want to impress, but at the same time need to be wary of the tech demo mentality.
(I think this was still somewhat on-topic? 
)
Currently I spend 50% of the CPU time on updating the full sprite colour table every frame.
But my real grand plan to free up CPU time is to make the game run at 30 fps, while updating all the motion at 60 fps (scroll + sprite positions). This means the input handling, game logic, collision detection, tile animations, sprite animations and z-sorting, all this expensive stuff gets spread out over two display frames. This will give a lot more breathing room, and since the motion updates at a higher frequency, the game will still appear smooth.
I understand you brother 
About the last part, you can get inconsistent frame data if the logic is for 30 fps and draw for 60, as for the 1st half drawing you may be using false data that changes on the 2nd part of the logic execution.
Or probably you are thinking about interpolation, shadow copy the last frame data, and while executing the next one interpolate that data between 2 frames.
I would target 30 fps with single page scroll. And use the resources (and time required) for other more enriching things like more animated tiles, different characters logic, etc.