Log In  

Cart #46265 | 2017-11-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Spritesheet Generator Demo is a cartridge that demonstrates how to save on-screen graphics into a cartridge's permanent sprite memory. Useful for programatically generating sprites. It is not a useful/playable cart; it is intended for use as example code.

Includes a standalone setsprites() function to use in your own projects (which must be followed by cstore() to save permanently to the cartridge). Also includes a replacement circfill() function (not stand-alone) in order to render the intended example graphics.

(Also, my first upload to the BBS.)

P#46266 2017-11-14 00:10 ( Edited 2017-12-16 23:04)

So this is like a in-game screen capture type thing?

Say I had a game where you wanted to a take photograph of what's currently on screen and then display it later...this would let me do that?

Sounds cool...gonna have to dig in an try it.

P#46290 2017-11-14 13:35 ( Edited 2017-11-14 18:35)

Yes, you could theoretically use this to save/redisplay the screen. But, in order to capture the WHOLE screen, you'd have to overwrite the entirety of the sprite sheet memory - every bit of it, including the "shared with maps" memory.

That's because every sprite sheet has as enough space to store the equivalent of 1/4 of a screen's worth, and there are 4 sheets (counting the two shared with the tile maps).

So, if you did this, you could not use other sprites at all in your game, at least not without swapping them in/out from other cartridge files, or storing their data in code, or other such sticky tricks.

There's a lot more memory available to the running program's variables (2MB) than there is in the so-called "base ram" described in the manual (32kb), and most of that base ram is taken up by things you don't want to be overwriting, so if I was doing screen capture, I'd probably just examine each pixel one by one and save it into a table, then write it back out like that. But that is much slower than directly copying memory...

Another technique that would be possible, would be to use cstore() with its filename parameter, and copy the screen memory directly to a separate cartridge rom file, and then read it back in from that. I haven't done anything involving that myself, and am worried it might be easy to accidentally overwrite rom files you didn't mean to, so I'd be somewhat hesitant to use that technique. On the plus side, though, it would mean your saved screen data could persist across multiple sessions.

Anyway, the code to do that would be something like (untested):

cstore(0, 0x6000, 0x2000, "imagefile.p8") --save
reload(0x6000, 0, 0x2000, "imagefile.p8") --restore

0x6000 is the start of the screen's memory, 0x2000 (8192) is how many bytes the screen takes up.

P#46291 2017-11-14 16:32 ( Edited 2017-11-14 21:32)

No type...

P#47453 2017-12-16 18:04 ( Edited 2017-12-16 23:04)

[Please log in to post a comment]