Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: the ability to copy from screen/buffer to current bitmap #117

Open
prgp opened this issue Oct 22, 2023 · 3 comments
Open
Labels
enhancement New feature or request

Comments

@prgp
Copy link

prgp commented Oct 22, 2023

Currently we can copy an image into the current bitmap using:

VDU 23, 27, 1, w; h; b1, b2 ... bn

Then copy from current bitmap to screen / buffer:

VDU 23, 27, 3, x; y;

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:

VDU 23, 27, 32, x; y; w; h;

(It would have been nice if there was a space between the bitmap and sprite operations to allow for possible expansion - I have picked 32 above as it does not clash with an existing command, but ideally it would probably be 4 with sprites operations starting at either 16 or 32 ...)

Additional Related "nice to have" Features

Also potentially useful would be:

  • the ability to read a rectangle of screen pixels - the bulk equivalent to VDU 23, 0, &84, x; y;
  • the ability to read a bitmap back onto ez80- a companion for VDU 23, 27, 1, w; h; b1, b2 ... bn - probably could use the same serial packet as above
  • the ability to clear a single bitmap
  • the ability to use flipped bitmaps in sprites
@stevesims
Copy link
Contributor

Curiously I wrote a comment on this very functionality earlier today on the AgonConsole8/agon-vdp repo 😁

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 😁 )

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. 😁

Also at least some of the other things you've mentioned are already there. 😁

@stevesims
Copy link
Contributor

see AgonConsole8/agon-vdp#103

needs some enhancements to vdp-gl, but I believe I have something that's working

@stevesims
Copy link
Contributor

the "copy screen to bitmap" feature was included in AgonConsole8 agon-vdp 2.2.0 release

PR #153 adds support for this for Quark. NB this requires an updated/revised vdp-gl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

3 participants