I have noticed the separate issue whereby the screen's display file is updated slightly before the attribute file. This is most noticeable in rooms where the background's INK and PAPER settings are different, and fast-moving elements traverse the screen. e.g. arrows in a room with a rope, where it manifests itself in the arrows flickering in a different colour to the usual white (in that example, the arrows would be seen for the briefest of moments in the same colour as the rope).
I have thought some more about the above, and carried out some investigations. It seems to be a related phenomenon to the one which Norman has identified.
PREAMBLE: For my investigations, I inserted several arrows of the same 'Guardian Class' into a room, in which I had assigned differing values for the Air's INK and PAPER settings. (Red INK on Cyan PAPER - both of which contrast well with each other, and also with the White colour of the arrows.)
The effect described above was clearly visible, whereby an arrow's graphic bytes are drawn to the next cell along the arrow's path, in advance of that cell's INK setting being updated in the attribute file. This causes the arrow to flicker for the briefest of moments in red (the background's INK setting).
Furthermore, the effect was much more pronounced for an arrow that fired along the top of the screen, than for one which traversed along the bottom of the screen. For two arrows which occupy the same cell-row, but different pixel-rows, the effect was more pronounced in the arrow that passed along the upper pixel-row. But within the same vertical half of the screen, an arrow in the top pixel-row of a cell-row at the bottom of the screen (row 15) displayed the effect more prominently than an arrow in the bottom pixel-row of a cell-row higher up the screen (row 8).
This pattern is not surprising, bearing in mind the previous discussion about how the screen is drawn in JSW. The prominence of the effect is proportionate to the time delay between the arrow being drawn, and the colour-attribute of its host cell being updated.
(With Norman's alternative screen-drawing routine in place, I suspect that the prominence of the effect would follow a simple linear progression down the screen, although I haven't checked that.)
This gives rise to the possibility of coming up with a further rearrangement of the code to diminish this effect, building on Norman's methodology. Could Norman's new code be modified so that the attributes along each cell-row are updated from the attribute buffer immediately after all eight pixel-rows for that cell-row have been copied from the display buffer?
i.e. Pixel-rows 0-7 of cell-row 0 are drawn, and then the updated attributes are inserted across cell-row 0, before cell-row 1 is considered?
EDIT: If such an approach were to be implemented and if you wanted to use the unused 'Screen Flash' routine [a relic from Manic Miner, where it is enacted once an extra life is gained] within a project, then the Screen Flash part would need to be reinserted in the Main Loop (to overwrite the PAPER colour of every screen cell in the secondary attribute buffer) before any of the screen (graphic bytes or attribute bytes) is updated during the Main Loop.
Incidentally, I gave the example of arrows because the effect (which we should probably think of a suitable name for) is most noticeable, since arrows are so fast-moving. But you can also observe it with guardians (especially fast-moving vertical ones) in rooms with non matching INK and PAPER settings for the background. See the Cyan Security Guard in the blue rooftop room 'I'm sure I've seen this before' - the top of the guard's helmet or its feet, at the point when those elements cross into a new cell-row - or the horizontal Green Bird in same room - watch its beak as it flies into a new cell-column.
You can also observe the effect quite prominently when Willy falls through 'Entrance to Hades' (where the background has Green INK on Yellow PAPER). It isn't generally as noticeable with Willy whilst he is walking, because his sprite is quite narrow, and so his colour-attribute actually moves forward in advance of the inked-in part of his sprite. (That's why he can perch on the edge of a block when it appears there is nothing underneath him supporting him.) But in 'The Nightmare Room', where Willy is in Flying Pig mode, his sprite is quite a bit wider than usual, so if you POKE the Air INK in there from the default Black to Magenta, then as it walks around you can sometimes catch the pig's snout turning pink (appropriately enough!)
Edited by IRF, 22 October 2017 - 11:00 AM.