stevesims
commented
1 year ago Curiously I wrote a comment on this very functionality earlier today on the AgonConsole8/agon-vdp repo :grin:
I've been thinking about implementing this functionality for a little while now. Recent changes to how bitmaps are handled make this much more practical to implement. A few brief notes...
Generally our VDU commands follow Acorn's lead.
Acorn used VDU 23, 27, 1, n, 0, 0, 0, 0, 0, 0 to define a bitmap (what they called a sprite). We have used this command instead to define a bitmap...
The Acorn version of this command takes the last two graphics cursor positions to define the rectangle of screen to grab.
On the surface, there's a conflict here with the command we have on the Agon. Acorn's command includes the bitmap number, whereas the command we currently have doesn't, and instead that byte is half of our width 16-bit value.
However - we can potentially implement Acorn's version, pretty much exactly as-is.
Our interpreter for VDU 23, 27, 1 could look to see if there's a height of 0 sent - and from that it could trigger "define bitmap from screen" mode.
Some further notes...
The bitmap system was recently update to use the buffers system added in the buffered commands API for storage, which opens up lots of possibilities for bitmap processing. See #97 for more info on the features that adds.
The new buffer-backed bitmap system maps the existing 8-bit bitmap IDs to 16-bit buffer IDs that are in the range of &FA00-FAFF, or 64000-64255.
VDU 23, 27, 32 is already command that selects a bitmap using a full 16-bit ID, allowing more than 255 bitmaps to be used (again, see #97 ). (Yeah - I'd have put a gap between the bitmap and sprite operations too :grin: )
Flipping bitmaps is quite easily done using the buffered commands API. (Flipping is slightly easier, conceptually, when you're using 8-bit bitmaps rather than 32-bit ones, which are now supported. I'm pretty sure I wrote examples in the docs.)
Clearing a single bitmap is now possible - just delete the buffer that it's stored in with the buffered command API.
Your ideas around sending data back to the eZ80 are also on my radar. That would most likely be done by sending data from a buffer. There's details to be worked out for this tho, so that might take a bit longer.
In conclusion - there's no need to define a new command for the "define bitmap from screen" functionality - the command is already there, it just hasn't been implemented yet. :grin:
Also at least some of the other things you've mentioned are already there. :grin:
Currently we can copy an image into the current bitmap using:
Then copy from current bitmap to screen / buffer:
The Request
It would be really useful to be able take a generated image from the screen (or from the buffered screen if in a double buffered mode) and copy into a bitmap so that it could be redrawn quickly later or easily duplicated on screen (like a tile).
For Example:
(It would have been nice if there was a space between the bitmap and sprite operations to allow for possible expansion - I have picked
32above as it does not clash with an existing command, but ideally it would probably be4with sprites operations starting at either16or32...)Additional Related "nice to have" Features
Also potentially useful would be:
VDU 23, 0, &84, x; y;VDU 23, 27, 1, w; h; b1, b2 ... bn- probably could use the same serial packet as above