Saving a sprite in a sprite area

[Paul Sprangers]

Dear all,

I managed to use ChangeFSI in my BASIC program for rescaling a JPEG and
re-typing it to a sprite. The resulting sprite is saved to disk, as a
single sprite file.

However, what I want to achieve is that the resulting sprite is saved to an
existing sprite file that contains more than 60 sprites. It should thereby
overwrite a particular sprite with the same name in that file.

The most likely call seems to be SYS"OS_SpriteOP", but I can't find a
reason code that does exactly that. The reason codes that I tried
nevertheless, either cause a corrupt sprite file or don't do anything
noticeable at all. What should I do? (rather than giving up on trying to be
a programmer).

Kind regards,
Paul

[druck]

Post by Paul Sprangers
Dear all,
I managed to use ChangeFSI in my BASIC program for rescaling a JPEG and
re-typing it to a sprite. The resulting sprite is saved to disk, as a
single sprite file.
However, what I want to achieve is that the resulting sprite is saved to an
existing sprite file that contains more than 60 sprites. It should thereby
overwrite a particular sprite with the same name in that file.
The most likely call seems to be SYS"OS_SpriteOP", but I can't find a
reason code that does exactly that. The reason codes that I tried
nevertheless, either cause a corrupt sprite file or don't do anything
noticeable at all. What should I do? (rather than giving up on trying to be
a programmer).

Create a large enough sprite area for both sprites files with
OS_SpriteOp 9, load the 60 sprites file with OS_SpriteOp 10, and merge
in the new sprite with OS_SpriteOp 11, and save with OS_SpriteOp 12.

---druck

[Paul Sprangers]

Post by druck
Create a large enough sprite area for both sprites files with
OS_SpriteOp 9, load the 60 sprites file with OS_SpriteOp 10, and merge
in the new sprite with OS_SpriteOp 11, and save with OS_SpriteOp 12.

Ah... merge. Why didn't I think of that?

Is that one sprite area for both sprite files, or should both files have
their own area?

And is it really OS_SpriteOp 9 - 12, or should I add 256 to those numbers?
(That's what the StrongHelp manual suggests).

Thank you for putting my on the right track
Paul

[Paul Sprangers]

Post by Paul Sprangers
Is that one sprite area for both sprite files, or should both files have
their own area?

A bit of experimenting shows that one sprite area should do.

Post by Paul Sprangers
And is it really OS_SpriteOp 9 - 12, or should I add 256 to those
numbers? (That's what the StrongHelp manual suggests).

Another bit of experimenting shows that 256 should indeed be added to the
original reason code.

Some of the sprites that I merged to the sprite area have overwritten the
original one as intended, but a lot of others delete all sprites in the
sprite area, after which the file consists of the new sprite only. And I've
no idea where that comes from. Here is my code:

$spritepath% = path$
SYS "OS_SpriteOp, 265+11, sparea%, spritepath%
SYS "OS_SpriteOp, 256+12, sparea%, originalpath$

- spritepath% contains the path of the sprite to be merged.
- sparea% is the sprite pool that contains the 60 sprites file.
- originalpath$ is the path of that 60 sprites file.

The sprite to be merged has the same name as its file name (both "player"),
which is the name of a sprite in the large sprite file too. The latter
should be replaced by the new sprite. Sometimes it does, but mostly the new
sprite replaces all sprites, as said.

The new sprite is never larger than approximately 3500 bytes, reason why I
add a sufficient 5000 bytes to the length of the sprite pool (sparea%).
So, what am I still doing wrong?

Paul

[druck]

Post by Paul Sprangers

Post by Paul Sprangers
Is that one sprite area for both sprite files, or should both files have
their own area?

A bit of experimenting shows that one sprite area should do.

One area to hold both the loaded and merged sprite files.

Post by Paul Sprangers

Post by Paul Sprangers
And is it really OS_SpriteOp 9 - 12, or should I add 256 to those
numbers? (That's what the StrongHelp manual suggests).

Another bit of experimenting shows that 256 should indeed be added to the
original reason code.

Yes, as it's a user sprite area.

Post by Paul Sprangers
Some of the sprites that I merged to the sprite area have overwritten the
original one as intended, but a lot of others delete all sprites in the
sprite area, after which the file consists of the new sprite only. And I've
$spritepath% = path$
SYS "OS_SpriteOp, 265+11, sparea%, spritepath%
SYS "OS_SpriteOp, 256+12, sparea%, originalpath$
- spritepath% contains the path of the sprite to be merged.
- sparea% is the sprite pool that contains the 60 sprites file.
- originalpath$ is the path of that 60 sprites file.
The sprite to be merged has the same name as its file name (both "player"),
which is the name of a sprite in the large sprite file too. The latter
should be replaced by the new sprite. Sometimes it does, but mostly the new
sprite replaces all sprites, as said.

I've no idea what is happening there. I would try debugging by saving
the area to different files before and after the merge, to check if it
really the merge going wrong and not something else.

Post by Paul Sprangers
The new sprite is never larger than approximately 3500 bytes, reason why I
add a sufficient 5000 bytes to the length of the sprite pool (sparea%).
So, what am I still doing wrong?

That should be sufficient, there would be an error if it were not.

---druck

[Paul Sprangers]

Post by druck
I've no idea what is happening there. I would try debugging by saving
the area to different files before and after the merge, to check if it
really the merge going wrong and not something else.

That appeared to be a very good advice: it went wrong *before* the merge,
because at some point in the routine I stupidly used the sprite pool for a
buffer, rather than a specific buffer. Thank you David, problem solved.

Paul