sprite pain

For newsuk I need to dynamically load sprites into a spritearea.
I have no idea, how many or how large the sprites will be until they are downloaded and processed.
The only way I can see to get the size of a spritefile is to look in the “header” of the spritefile. I’m guessing the first 4 bytes are the number of sprites, then the next 4 is the total size of the spritearea.
Then I can use flex to allocate an area of memory, initialise it and then load the spritefile into it, and update the spritearea pointer variable in toolbox.
When the second file comes along, I’m guessing I need to do the same again – then create a sprite area the size of the first and second, initialise it, then merge the sprite areas, update the pointer in toolbox then free off the two single sprite areas.
Rinse and repeat.

Am I missing something or is it a wee bit fiddly?

I can see that in tboxlibs.h.wimp there is a struct called is which contains void *sprite_area, so I’m guessing it may be possible to have a sprite_area per icon – which would be ideal.
And set the “button” to “Use client’s sprite area”

From what I’ve seen I need to use one sprite area :-( and if I use flex I’ll need to create a new one and free the old one…

The only way I can see to get the size of a spritefile is to look in the “header” of the spritefile. I’m guessing the first 4 bytes are the number of sprites, then the next 4 is the total size of the spritearea.

No. The second word is an offset to the first sprite.
The size of a sprite area does not need to be defined anywhere. It is the size of the sprite file plus four bytes. Essentially, a sprite file is a dump of a sprite area, minus the size.
Take a look at PRM p1-779.

When the second file comes along, I’m guessing I need to do the same again – then create a sprite area the size of the first and second, initialise it, then merge the sprite areas, update the pointer in toolbox then free off the two single sprite areas.
Rinse and repeat.

Why not work out how much space you need, extend the original sprite area accordingly (flex_extend()), fiddle the size word to take this into account, then load the second file into the newly enlarged sprite area.
…take a look at how !Paint does it…

Am I missing something or is it a wee bit fiddly?

Are you certain that there is no possibility of a new sprite having the same name as one already loaded? It’d overwrite…

Are your sprites predictable? I mean as in “I’d normally get about this many icons of such and such a size”? If so, you could work in a pro-active (!) manner and allocate a suitable amount of memory at the beginning, and only resize it if it overruns.

Why not work out how much space you need, extend the original sprite area accordingly (flex_extend())

Hmmm, flex.
IIRC there was a shortish discussion out on the newsgroups about the failings of the RO implementation recently

Thanks, I spent 30mins in the PRM’s and 30mins in the header files last night ;-) not the easiest of reads!
Ah, I had assumed that flex_exend didn’t extend into a contiguous block – I must have misunderstood from the header files! That makes it vastly easier. Wonderful!
At the moment I’ve deliberately named the sprites so that for each feed the sprite names are numerically increasing, so at the moment although I load the sprites into the main pool when the next feed loads the first sprite in the feed overwrites the previous first sprite, the second the second etc.
When ChangeFSI processes the sprite it gives the sprite the name of the original file, so I use that to ensure spritenames are unique per feed.
For newsuk the issue isn’t too bad, but when I eventually get the base code good enough to write a generic RSS reader there could be hundreds of sprites to deal with all of varing sizes – clearly in this case I’m going to have to do something more intelligent than do a bulk convert of say 100+ images in one go – but that’s another challenge to tackle.

Hmmm, flex. IIRC there was a shortish discussion out on the newsgroups about the failingsof theRO implementation recently

URL? The most recent that turned up for me was… https://groups.google.com/forum/?nomobile=true#!search/comp.sys.acorn.*$20flex|sort:date/comp.sys.acorn.programmer/dVp6A2Ey-ww/F4UT99KjLMMJ

When the second file comes along, I’m guessing I need to do the same again – then create a sprite area the size of the first and second, initialise it, then merge the sprite areas

Well… yes and no.

Pedantically speaking you don’t need to merge the two areas, you can just make the last sprite in the first area point to the first sprite in the second area.

The first word of a sprite is defined as the offset to the next, not the size of this sprite. This is something that ROL changed (in their typical half-arsed fashion) such that some sprite calls would fail if the offset wasn’t positive, but others worked fine (they only introduced this innovative interpretation of the word ‘offset’ in SpriteExtend I think). I had to write a diddy module to fix it – SpriteXFix.

I don’t know if RO5 has done anything naughty with the sprite definition (I doubt it, we’re all sensible this side of the fence, yes?) but you may want to check.

Anyway, chaining sprite areas like this is absolutely fine according to the spec (as long as you’re not asking the sprite code to create any new sprites).

Anyway, chaining sprite areas like this is absolutely fine according to the spec (as long as you’re not asking the sprite code to create any new sprites).

Well, I hate to break it to you, but since at least 1996 OS_SpriteOp 17 has considered sprite areas containing offsets which point outside the area to be invalid. And I’m inclined to agree with it, no matter what the spec may suggest.

https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Video/Render/SprExtend/c/Attic/SpriteOp?rev=4.1;content-type=text%2Fx-cvsweb-markup;hideattic=0#l57

And in 2002 it was tightened up further to disallow negative offset values.

Well, I hate to break it to you

Think of it like a layman’s interpretation of continental law – namely that which is permitted is permitted, everything else is not.

In other words, just because nothing in the documented API specifically disallowed using sprite areas in this way doesn’t mean it was ever safe (or even a good idea) to do so.
Remember how many whizzy disc protection systems broke with RISC OS 3? Remember how many also fell flat on their faces when the combi-I/O chip differed in subtle ways to the 1772? Remember how much stuff broke when SYS "OS_UpdateMEMC", 64, 64 not only stopped working on RISC OS 3 but instantly stiffed the machine? Remember how much stuff looked dead weird on RISC OS 3.5+ because it never bothered following the API for correctly setting colours and now suddenly those bits that had no meaning before (and should have been clear) suddenly did something…

To the OP, I suggest (again!) to look at Paint’s code to see how it handles this sort of thing.

And in 2002 it was tightened up further to disallow negative offset values.

That looks like a merge of some sources not in CVS, since it was committed by kbracey but has JRF (Justin Fletcher’s) initials next to it.

However, that code’s not used in RISC OS 5 any more (as it’s in the attic). I reimplemented the validation sprite op based on the algorithm listed in the PRM, so you can have negative relative offsets but the resulting image must be within the sprite area as a whole.

As Jeffrey says, that seems reasonable, otherwise saving the sprite area would require following a list of sprite pointers and somehow lassooing the area required to enclose it.

@Rick Sorry I have been looking at it, I had to get some “quality” time to sit down and look.
My initial reply was before I’d had chance to go through it, as at that time I’ve only had a strong coffee and not yet had my English Breakfast Tea.
Not forgetting intercontinental law….Do what we say or we’ll nuke you ;-)
I’ll probably need to look at it another three times before I’m 100% sure, but that’s not the coding fault – it’s my lack of experience.
I have some mad ideas to play around with flex (useful idea I think, but mad nevertheless!)

that code’s not used in RISC OS 5 any more

Good, it was never consistent anyway – only some calls checked.

the resulting image must be within the sprite area as a whole.

I have no problem with the “validation” call complaining about unusual constructions, but turning normal calls (which DO things) into validation calls (which try to find a reason NOT to do them) is pointless and self-defeating. In particular, introducing an error where previously there was none is a break of (api) contract, in effect.

that seems reasonable, otherwise saving the sprite area would require following a list of sprite pointers and somehow lassooing the area required to enclose it.

Again, if save is implemented in a way that requires a certain memory arrangement (contiguous monotonic ordering for example) then it is fine for it to error when you try to save something more complicated (and it’s not hard to use multiple GBPB calls anyway). However, it is not OK for the normal ‘find sprite’ routine to suddenly take it upon itself to error the paint you are doing in anticipation of the save you might do.

I can’t stress that strongly enough.

I boggle at the thinking that leads to this kind of throttling of capability. I think that mindset is more suited to tax inspectors and parking attendants.

just because nothing in the documented API specifically disallowed using sprite areas in this way doesn’t mean it was ever safe (or even a good idea) to do so.

Sprite Ops have always supported direct addressing (ops &200+). Such calls that only use the sprite pointed to by R2 have never needed a valid R1 nor anything particular at this sprite’s offset. So the “sprite area” is entirely irrelevant in those cases.

a break of (api) contract, in effect.

and

Such calls that only use the sprite pointed to by R2 have never needed a valid R1 nor anything particular at this sprite’s offset.

I think you are confusing published API with “insider knowledge”. While it makes a sort of sense that if you pass a direct address of a sprite there is no need to specify the sprite area, I quote:

Stated quite clearly in PRM 1-781 (and paper versions). Now, you might not actually need to set R1. The documentation says that you should therefore this is the published API that programmers should work with. It is not up to us to try to second-guess the OS.

I can’t stress that strongly enough.

Again, I ask you where it states that it is acceptable to have a sprite offset pointing to seemingly random pieces of memory. As far as I can see, it does not state that this is an option. Rather, it is an assumption that has been made that now stands to fail if the sprite handler tightens up its checks on the integrity of sprite areas (which, provided such checks do not contradict the published API, it should be free to do – again, it is not up to the programmer to second-guess what the OS is actually doing – I cannot stress that strongly enough <wink>).

I note that p1-776 says: Unlike the system area, there can be several user areas which are referenced via pointers to the start of the areas.
Now we need to discuss is a sprite area comprised of numerous independent memory claims a valid sprite area, or is it a mish-mash of what really ought to be separate areas?