About the Lou's pseudo 3d Page, I am more optimist. Some solutions proposed there are suitable to be implemented with fixed point math and have been used
I have been using this technique for my Outrun MSX2 demo. It takes about 40k cycles to compute a frame. So it can be done on an MSX. The problem does not lie in computing but in rendering. And that's where the MSX is less able than other computers.
Precomputing the road will not improve the situation because, again, the bottleneck is in rendering the frame.
Very nice demo! ... Updating 2 banks of tile colors (I think that's what he does there) will take more time on the MSX: 29x4096=118 784 cycles, so rendering would take a little less than 2 frames @50Hz. Probably less because a part of rendering would occur in VBLANK, therefore without OUT speed limits.
If Rasmus does not release its sources, I could try to port the Outrun MSX2 demo core code to MSX1, using his rendering technique. The computing core would be exactly the same, it would need only the rendering core to be rewritten.
With 40k cycles for computing and 120k cycles for rendering, it means that the framerate would be at around 20 fps, without sprites, music or game logic. Still, doable I think.
Very nice demo! ... Updating 2 banks of tile colors (I think that's what he does there) will take more time on the MSX: 29x4096=118 784 cycles
the ti-99 has slower vram access than msx because the vdp brake is hw based and always active.
so performances on msx should be better than on ti-99
on the other hand the ti/99 cpu is a 16 bit and may be faster than z80 on non VRAM operations...
Very nice demo! ... Updating 2 banks of tile colors (I think that's what he does there) will take more time on the MSX: 29x4096=118 784 cycles, so rendering would take a little less than 2 frames @50Hz. Probably less because a part of rendering would occur in VBLANK, therefore without OUT speed limits.
If Rasmus does not release its sources, I could try to port the Outrun MSX2 demo core code to MSX1, using his rendering technique. The computing core would be exactly the same, it would need only the rendering core to be rewritten.
With 40k cycles for computing and 120k cycles for rendering, it means that the framerate would be at around 20 fps, without sprites, music or game logic. Still, doable I think.
I'm proposing him to use a double buffering scheme close to the one used in Uridium in order to have two VRAM pages that can be shown alternatively.
You roll the pattern tables repeating the first bank 3 times, and use only colors in the second and third banks.
In this way you get:
Page 0 has patterns in 0x0000-0x07FF (filled by F0h) and colors in 0x2800-0x37FF
Page 1 has patterns at 0x2000-0x27FF(filled by F0h) and colors at 0x0800-0x17FF
With this double buffering scheme you can plot directly in VRAM using e.g. a differential scheme, for road and for bitmap items hiding the plotting phase (that could be longer than one frame).
The side effect is that you can use only 8 sprites and that the top 3rd of the screen cannot be used freely.
But is not that bad, as you could use the sprites e.g. for clouds or score in the 3rd top of the screen
I agree. Very impressive, however I feel the need to point out that it’s not wise having water next to the road when there is a hill climb. Not that realistic that the water levels suddenly becomes 3 meters higher too
