Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #6387 > unrolled thread

Saving a sprite in a sprite area

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Saving a sprite in a sprite area Paul Sprangers <Paul@sprie.nl> - 2022-06-13 11:51 +0200
    Re: Saving a sprite in a sprite area druck <news@druck.org.uk> - 2022-06-14 10:02 +0100
      Re: Saving a sprite in a sprite area Paul Sprangers <Paul@sprie.nl> - 2022-06-14 12:33 +0200
        Re: Saving a sprite in a sprite area Paul Sprangers <Paul@sprie.nl> - 2022-06-14 14:00 +0200
          Re: Saving a sprite in a sprite area druck <news@druck.org.uk> - 2022-06-14 21:12 +0100
            Re: Saving a sprite in a sprite area Paul Sprangers <Paul@sprie.nl> - 2022-06-15 09:50 +0200

#6387 — Saving a sprite in a sprite area

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

[toc] | [next] | [standalone]

#6388

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

[toc] | [prev] | [next] | [standalone]

#6389

In article <t89irm$r07$1@dont-email.me>,
   druck <news@druck.org.uk> 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

[toc] | [prev] | [next] | [standalone]

#6390

In article <59f86074f3Paul@sprie.nl>,
   Paul Sprangers <Paul@sprie.nl> 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

[toc] | [prev] | [next] | [standalone]

#6391

On 14/06/2022 13:00, Paul Sprangers wrote:
> In article <59f86074f3Paul@sprie.nl>,
>     Paul Sprangers <Paul@sprie.nl> 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

[toc] | [prev] | [next] | [standalone]

#6392

In article <t8aq3u$v6u$1@dont-email.me>,
   druck <news@druck.org.uk> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web