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

--
https://riscos.sprie.nl

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/06/2022 10:51, Paul Sprangers wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <t89irm$r07$[email protected]>,
druck <[email protected]> wrote:

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

--
https://riscos.sprie.nl

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Paul Sprangers <[email protected]> wrote:

To answer my own questions:

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.

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

--
https://riscos.sprie.nl

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/06/2022 13:00, Paul Sprangers wrote:

In article <[email protected]>,
Paul Sprangers <[email protected]> wrote:

To answer my own questions:

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.

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.

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.

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <t8aq3u$v6u$[email protected]>,
druck <[email protected]> wrote:

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

--
https://riscos.sprie.nl

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)