MSX1 Smooth scroll gpu accelerated

It is an unconventional idea, to say the least

It depends on the games you want to 'smoothen', of course, but assuming that their 'average' scroll speed is '1 pixel per frame' that would mean you would need 8 frames of delay in order to be able to obtain 2 snapshots between which you want to interpolate. That would make the game experience extremely laggy and unplayable.

Even if we assume the scroll speed is twice as fast, you'd still have 4 frames of delay which is not good.

The problem is that many of these old games are tough-as-nails and really require split-second reactions. Any introduced lag will frustrate the game-play experience.

I was trying to think of MSX 1 games that have really fast scrolling where this trick might work. Thexder comes to mind, but looking at it, I would guess it is still 4 frames between individual foreground updates?

You cannot see into the future without making wrong guesses about user input.

If you want to 'fix' that, you would need to take the current user input and assume this is what it will be in the future. That means storing the steering input in a queue and then pull it out of the queue when the MSX itself does the calculations for the frame which is by then already considered to be in the past. It depends on the length of the queue how many frames of delay you will introduce, but overall it is not good.

The concept you are proposing is basically the idea that Google engineers postulated to reduce lag on Stadia called "Negative Latency". The concept there is to simulate forwards for 'all possible input' combinations and then pick the frame that matches with the 'actual inputs' by the time you get there. Many people agree though that this very hard to pull off because there is just too much 'state' in modern games and the 'space' of potential input data per frame is very large. The amount of memory and computational power you would need makes this idea rather unpractical.

Now, you could argue that, for MSX, the amount of different inputs is smaller if you just assume keyboard and/or 8-way joysticks. But it still leaves a lot of button combinations you'd need to simulate forwards in order to have the correct frame constructed on time.

Fair enough, if you want to reduce the application of your technique to only games that do 'slow and monotone' scroll directions, then this would simplify it a bit.

Still, many of these games animate player weapons (e.g.: lasers), large explosions, (sub)-bosses, etc. by changing characters on the screen. And these things often move much faster than the scroll speed and have a dependency on user input.

So the resulting frames you obtain by forward simulation are most likely not 'clean' and you would somehow need to extract just the background pixels from that.

Even if you manage to do that; you would still need to put everything together and you end up with smoothly scrolling background and still 'jerky' movement for everything else that applies animations on the screen by changing characters?

(To be fair, Space Manbow also has that. In the first stage, for example, the ships that 'lift off' from the large ground vehicle animate upwards in steps of 8 pixels at the time).

https://youtu.be/iK7TfeGIhJ4
This is using 512 tiles for scrolling 2 pixels at step
All tiles are pre-loaded in vram

Yes so the first posted comment of this thread it was suggested a powerful processor running an emulator inside a msx cartridge to eliminate the lag.