Enhance send screen char functionality

[stevesims]

The existing command to send the character on-screen at a given coordinate will fail to work correctly for characters that are less than character 32. Now that the VDP allows those characters to be used and printed we should probably change that

Additionally the matching is currently strictly at character position - requiring the x/y parameters given as 16-bit values, which is kinda daft, which will be multiplied by 8 to get the screen pixel coordinates for that character (which assumes fixed font character size). We should consider ways to expand the functionality to allow for looking for characters at screen position, either using OS coordinates, or using screen pixel coordinates.

The algorithm also does matches based on the current text background colour. We may also wish to consider options to allow for matches based on the currently selected text foreground colour.

[lennart-benschop]

Or maybe have an additional buffer that contains the character codes of all characters printed to the screen at each position. It's a small overhead in terms of RAM and runtime, but it makes send_screen_char much easier and it will then work whatever colours were changed in the meantime. BTW, my MODE 7 (Teletext) implementation does just that.

[lennart-benschop]

One problem is that such a shadow buffer interacts with all kinds of other commands, like scrolling and text window setting. And it won't do fractional character positions (pixel granularity) either.

[stevesims]

yeah - I'm not really sure that it's worth optimising this functionality. I doubt this "read character from screen" is used all that much, so it doesn't need to be fast. if the line-editing system on the Agon had followed Acorn's model and used two text cursors, allowing for interactive copying of text from one part of the screen to another, then it would get used more, but this is a path not taken. maybe one day...

as you point out, there's also various commands that would either require complex modification of such a shadow buffer, or would potentially invalidate the buffer. scroll by 1 pixel and characters referenced by text position would all become invalid... scroll 7 more pixels so text is back to character-position alignment and the "read pixels and match" approach would work again, but a shadow-buffer approach wouldn't be able to recover.

[lennart-benschop]

Even if we had the Acorn model of copying text from screen to edit a line, then the screen read function would not need to be fast either. Human speed versus machine speed. I think the best we can do now:

• If a character cell has more than two different colours inside: don't bother.
• If a cell has two colours inside, pick one as foreground and the other one as background colour and construct a character pattern from the pixels. Then match against all 8x8 patterns in the font, starting at 32 (spacce), then 33..255, the range 0..31 comes last.
• If that matched a character: good. If that did not match a character repeat the search for the inverted pattern (all bits inverted).

[stevesims]

short term I think that just extending the current algorithm to also try to match characters 0-31 would be good. this is a simple fix, just changing a loop in the getScreenChar function in graphics.h so it iterates from 0 rather than 32

longer term, if/when we get support for changing fonts and/or supporting different sizes of font then that function will need a rewrite anyway. at that time we can revisit the screen reading algorithm that is attempting to read pixels from the screen to be more sophisticated

[stevesims]

release 2.7.0 implements recognising characters 0-31. they're checked after characters 32-255.