Shadow of the Beast on Amstrad CPC+!!

Agree, screen 4 is the best option for anything that scrolls horizontally in general. In this specific case especially, because since adjusting r#18 during command execution causes corruption, a screen mode that you can use without using copy commands is advantageous when you need to adjust it so often each frame. To avoid border flipping, covering them with sprites positioned independently for each scrolling band.

Screen 5 will be very tricky, with the multiple bands scrolling at different speeds. The method to scroll in screen 5 (back buffer copies spread out over multiple frames) becomes more complicated, because you do the back buffer copies and page flipping independently for each band. While at the same time the frequent scroll register adjustments make command executing very challenging.

and instead picking from the list "the amiga game that one cannot do" and whining
one could pick from the list "the things the amiga cannot do"
like wing commander on screen 8!!!

Excuse me but for "wobble" means the displacement because the horizontal adjust register? If so, for tiles I say the same than about sprites, I prefer to preserve resources for the game itself instead for masking some defects that are inherent to the hardware behavior.

All the tiles you should use to have them 1-7 pixel displaced with black could be used for animated tiles, much more enriching.

Yup, Multi-Plex is a technically very awesome game. Really shows the power of the V9958. Great fast and slow parallax scroll, day and night cycles, I also really like how the water level works. Every level uses different techniques, they were all crafted manually to be unique from the others. Must’ve taken a lot of time to make.

Longer video: https://youtu.be/ZgWxpggY49M

Great game, I was unawave (simply that time I didn't have Turbo-R). Smooth. But the planes clearly spliced horizontally. No overlapping planes and objects (like trees etc).
I'd like simply to understand whether SOTB experience can be recreated. For example we have Turbo-R. We can go as fast as R800 would allow with the memory and as fast as V9958 will let us on the I/O. Likely, things like trees, etc don't use more than 2 colors per scan line. The challenge would be to overload the sprites/pointers precisely just between two line fetch cycles of VDP. I would like to understand whether it's possible (that was the initial discussion subject, not the contest for the best platform where this thread seem to deviate).
Background: IMHO, the line interrupts in the MSX games show some artifacts when the screen is spliced for the score boards on some KONAMI games. Never have seen the back-to-back line spliced screen without any blank lines or artifacts. What I'm trying to point out is due to the variation of the MSX2/2+ architecture (VDP clock is coupled to CPU clock or independent, VDP waitstate machine is custom for every chip vendor etc), that normally designers took a conservative approach taking some design margings. Turbo-R, however, is the unique architecture, which can be well profiled and, hence, the code execution timing can be very tight. Also I wonder how the tighter R800 interrupt timing interacts with the 4us block refresh. Comparing to the 6502 based architectures (C64, Atari, NES) , unlike the 6502 which is running always from the same crystal as the video subsystem and sharing its cycles, Z80 based MSX architecture presents some additional challenges. These challenges are:
- The RAM refresh mechanism and number of additional waitstates per peripheral is not defined and open to the manufacturer.
- There is no standard way in the slot enumeration/autoconfig to supply the software agregator with the timing profile.
From the above, IMHO, every game designer was facing the challenge how to make the game with the great experience but still running accross the large variety of the architectures.
IMHO, if the MSX standard would be tighter or more verbous regarding the real-time extensions, the interrupts could even be better controlled. If it is possible on the AMIGA (68000 is the nightmare for the real-time interrupt based control) why it shouldn't be possible on the MSX?
Another IMHO:
There is a concept of the precise interrupts. Z80 has a large instruction execution time variance, which can't be interrupted (atomic), and hence represents the protential time jitter on the horizontal line interrupt latency. However, IMHO, with a very careful coding and instruction selection, this problem can be overcome.