The scrolling in Uridium works in screen 2 on msx1: you will have 60fps but you have to:
- live with color clash,
- use HW sprites,
- study the transition between tiles to make the transition tiles fit in the tile set
If you mean Uridium 2, it works on msx 2 in screen 8 at 60fps, but moving objects are restricted to HW sprites as the vdp is busy to move the screen.
If you mean Uridium 2, it works on msx 2 in screen 8 at 60fps, but moving objects are restricted to HW sprites as the vdp is busy to move the screen.
Yes, u2. However, do you think that by interleaving even/odd frames for scrolling / sw sprites it is feasible to get a decent frame rate?
Or the game mechanics will become too much complex?
I think one can work in sc5 to gain speed
I'm pretty sure that using the same strategy used in screen 8, one could safely implement SW sprites in screen 5.
I would implement 2 pixels as minimum step. This would boost the performances while drawing borders (up to the Z80) and moving background slices of 16x192 pixels (up to the VDP).
Under these conditions, you have plenty of spare time in the VDP and if the scrolling speed is constant and you admit changes of direction or scrolling stop only at multiple of 16 pixels (i.e. each 8 steps), the page swapping has a simple logic that could allow SW animations at 60/8 = about 7 Fps.
Anyway you should cope with the fact that the screen is moved slice by slice in 16 steps. This is not trivial when we go to background restoration.
I've been reading the thread, (by the google translator)
There is a reference: "Mais attention sur une même ligne horizontale on ne peut mettre au maximum that 4 sprites et sur tout l'écran 32, à moins que j'ai mal lut datasheet.
", which I think is wrong.
in sc4-sc8 modes (12 in 2+), the limit of sprites is 8 in line (32 on screen) with one color per line.
. 
