I believe there is only one possibility for producing an effective pure batch scrolling game - Every single frame (screen) of the static parallax background must be precomputed and stored, one frame per file. So for any background scroll position BG(x,y), there would be a file containing the escape sequences to generate the precomputed background image. For performance purposes, the masking should already have been computed so that each background "pixel" is represented only once. Obviously this design will result in a huge number of files.
The dynamic foreground images must then be superimposed on top of each static background frame. For each refresh cycle, you would need to compute your BG(x,y) position, retrieve the appropriate background file, and then superimpose your computed foreground images. I see two possible ways to do this.
1) The simplest method would be to simply TYPE the background image, and then use escape sequences to draw each foreground sprite in the correct screen position S(x,y). This would be the fastest option because it requires the least string manipulation, and it minimizes the number of bytes in the background image (less info to write to the console). But this would cause significant flicker with the foreground sprites. I'm guessing the flicker would be too much for my taste. I think it would severely limit my enjoyment of the game. But I can see how the frame rate might be pretty good.
2) The other option is to use the approach I used in my
latest version of BALLS.BAT. Each final frame to be displayed would consist of a series of strings, one string per horizontal line. Each pixel within a line would need to have a constant width that contains color and character information, so that you can effectively replace the static background pixels with the dynamic foreground pixels. The number of horizontal lines per frame is a constant, so you can use a FOR /L loop coupled with SET /P to read each line of the background into an array of variables that can then be manipulated to insert the foreground. Once the entire frame has been built, it would then be written to the console, and there would be no flicker.
As much as possible, the static foreground scaffold that the dynamic sprites interact with could be included somehow in each background file, but I have no idea what that data structure would look like.
The absence of flicker would be great, but the amount of string manipulation required would slow things down considerably. And having color escape sequences (perhaps both foreground and background) for every single pixel will dramatically increase the amount of info to be written to the console, which also will slow things down. I'm guessing that the frame rate will be pretty poor, perhaps to the point that the game is not enjoyable.
