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.
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).
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?
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 11:44:11 |
Calls: | 6,645 |
Calls today: | 5 |
Files: | 12,190 |
Messages: | 5,326,712 |