SpriteExtend issues?

Hello,
In my ongoing battle to render an alpha-blended sprite, I have tried using the below code:

osspriteop_put_sprite_scaled_mapped(osspriteop_NAME + 256,0,(osspriteop_id) ele->spritename,x,y,4,0,NULL);

On that running, I get a dialog which declares:

SpriteExtend: Bad colour translation table.

I feel, I’m making progress, but at the same time, somewhat stumped. I don’t know anything about the WIMP, so a code example would go a long way here to illustrate what I’m doing wrong. I cannot find a jot of documentation on how to do this, so I’m just randomly hitting keys at this point.

I’m using OSLib, if that’s an issue, I’ll change to plain SWIs if need be.

Cheers

Garry

Most OS_SpriteOp sprite plot calls require you to supply a translation table, which is used to convert the pixels between source and destination palettes.

The basic procedure for correctly plotting a sprite is:

1. Call ColourTrans_GenerateTable with R4=0 to read the required size of the translation table
2. If the returned R4 value is greater than zero:
   1. Allocate that much memory
   2. Call ColourTrans_GenerateTable again, passing in the buffer pointer
3. Now call your OS_SpriteOp, passing in the buffer pointer in R7.

If you’re going to plot the same sprite lots of times then it’s recommended to cache the translation table. You should be able to keep it until the next mode change, or until the screen (or sprite) palette changes. It’s also possible to share translation tables between sprites, if (a) they both have the same mode word and (b) they both have the same palettes.

Note that both ColourTrans_GenerateTable and OS_SpriteOp have a bunch of flags which control how the table is generated and used. You’ll generally want bit 4 of the ColourTrans_GenerateTable flags set, and bits 4 and 5 of the OS_SpriteOp flags.

Thank you Jeffrey, I really appreciate the help.

I am now attempting to generate a colourtrans table, and it runs without error, returning 8, as the length. I then allocate that memory, then run again, so I’m doing this:

void * generate_colourtrans_table(char * spritename) {

Then I plot like this:
osspriteop_put_sprite_scaled(osspriteop_NAME+256,0,(osspriteop_id) ele->spritename,x,y,osspriteop_GIVEN_WIDE_ENTRIES,0,ptr);

But then I get ‘Internal error: Abort on data transfer’.
I’m happy to supply the whole (sort of) working code, if that would help?

Is it possible that OSLib does not have the constants required for the new sprite plotting or something?

Many thanks again.

Garry

I can see two problems. The first is that you’re confused over how to specify the flags in the first argument to osspriteop_put_sprite_scaled(). You’re passing in osspriteop_NAME+256, but osspriteop_NAME is defined as being 256. So you’re actually passing in a value of 512, which is meant to be used when you’re providing a sprite area pointer + sprite pointer (see here). But you’re providing a sprite name pointer.

The second problem is that you’re mixing Wimp_SpriteOp and OS_SpriteOp calls. This is a problem because only the Wimp knows how to find sprites which are located within its sprite pool – OS_SpriteOp knows absolutely nothing about it. So if your sprite is located in the Wimp sprite pool, you should only ever use Wimp_SpriteOp to interact with it (i.e. wimp_spriteop_put_sprite_scaled in your case).

Also remember that the Wimp sprite pool is rather volatile – when you call Wimp_Poll another task could add or remove some sprites from the pool. So you shouldn’t cache any pointers to sprites which are in the Wimp sprite pool (or at least you shouldn’t cache the pointers across calls to Wimp_Poll). In your case I think the only time where you’d actually need to know the pointer to the sprite is when you’re generating the translation table.

And because the Wimp sprite pool is shared by all tasks, it’s generally considered bad form to put arbitrary sprites into it – the pool should only really be used for sprites which have had their name reserved (application sprites, file type icons, etc). If your program needs to use arbitrary sprites of its own creation then it should create and manage its own sprite pool(s). But since you’re just getting started I’ll let you off for now ;-)

Thanks for the help Jeffrey, my plotting still does not work, but I do feel I am at least beginning to understand some of the concepts.

I have reworked my code to only use ‘wimp’ functions. I appreciate it’s not cool to do this for any old sprite, but I’d like to get plotting working first and then I’ll see about making things the way they should be. My code is now this:

void verse_element_plot(verse_element * ele,wimp_draw * draw) {

}


I’m not using ColourTrans now, and now I get the below:

The funny thing is, if I switch into a 64k mode from my usual 16m colour mode, I get this:

Which almost looks better than the 16m mode, at least I can see the fade of the circle I’m trying to render, albeit in the wrong colours.

So I’m not quite sure about where to go with this. Does anything here strike you as wildly wrong?

The window is !PrivateEye showing the sprite which appears as square in my app…

Thanks
Garry

Hmm, I was just about to upload some screengrabs to illustrate my point, but !FTPc did not work, so I decided to restart. On restarting my Pi now will not boot RISC OS (it’ll boot Plan 9 on a different SD card). On putting the SD card into my PC it cannot see the FAT partition any more, so I assume it’s hosed.

I’ll need to find some time to fix this before continuing with my work. Still, I’d love to hear any ideas on how I can render an alpha blended image…

UPDATE: Recovered from backup, I expected it to take ages, but I’m back using RISC OS!

So I’m not quite sure about where to go with this. Does anything here strike you as wildly wrong?

I think there are two problems you’re seeing here:

1. You are setting the mode word to the correct value to indicate that the sprite has an alpha channel. But, if you’re using the same sprite as you were using here, then it looks like it also has a regular mask. This will confuse SpriteExtend, because sprites aren’t meant to have both an alpha channel and a mask at the same time. So try loading the sprite into Paint and removing the mask.
2. The green circles will be a bug in SpriteExtend where it’s not masking out the unused byte of a 16M colour word properly when performing some colour conversions. Or possibly it’s just a side-effect of SpriteExtend being confused by the sprite having both a mask and alpha channel (the ‘unused byte’ actually contains the alpha data). I suspect the bug will vanish if you fix the sprite by removing the mask. I’ll also investigate to make sure it’s not a general bug with SpriteExtend (I’ve checked all the sprite plotters on a BB-xM, but haven’t done full checks on the other machine types yet – so there may be a couple of bugs I’ve missed, due to the different CPU-specific optimisations SpriteExtend uses)

Hi Jeffrey,
Thanks for that, I am rendering two different sprites. One, which renders as a black circle, does have a mask. The one which renders as a square does not have a mask, at least according to !Paint. I tried removing the mask of the one which did have one, and now it renders as a square too.

If it matters, I’m now on RISC OS 5.21 (26-Feb-14), since I recovered from my disk woes. Before, I was on the 8th April build, if memory serves, although it appears to behave the same in this respect.

For some reason, since I recovered from my disk issue, I can no longer select a 64k mode. I’m using the same ‘HP LP2565’ monitor, in 1920×1080. However, to be honest, if my program only works in 16m colours, I’m OK with that. In this day and age of cheap and capable RISC OS machines (in no small part, thanks to you), 16m colours is easy to come by.

It doesn’t look like I’ll ever find the time (or remember) to write an example in C using OSLib and the Wimp, so here’s the next best thing I have available – a bona-fide RISC OS 5 format sprite with an alpha channel and a bare-bones example of how to render it using BASIC:

http://www.phlamethrower.co.uk/misc2/alpha.zip

If it matters, I’m now on RISC OS 5.21 (26-Feb-14), since I recovered from my disk woes. Before, I was on the 8th April build, if memory serves, although it appears to behave the same in this respect.

The OS version does matter; to date none of the Pi RC builds have support for the new sprite formats (or the 64K screen mode). You’ll have to use one of the nightly development builds. The 8th of April build should be fine, if you still have it.

Jeffrey, this is great. I put your sprite into the wimp sprite pool, and my program renders it in all it’s alpha blended glory.

So now I will see about tidying everything up to use it’s own sprite pool and continue with the rest of my application.

Thank you for your wonderful help, it’s really fascinating to see RISC OS render such images, opens up a lot of potential.

Jeffrey Lee, you are a good man.

Cheers

Garry

On a vaguely related note, how would I go about plotting a sprite where each pixel is effectively a mapping of how much to brighten/darken the pixel it’s plotted onto? E.g. assuming this sprite is 8bpp, if a bit has value 0, it means “darken a lot”, 127 means don’t change and 255 means “brighten a lot”. I assume I’m going to just have to implement this with a custom plotting routine – or is this something that can be bodged using clever alpha sprite plotting?

Thinking about it, I could maybe have a “darken” pixel as black, with the alpha channel controlling how much to darken that pixel. A “lighten” pixel would be white (again with the alpha channel controlling how much). And pixels that don’t affect the destination would be fully transparent in the alpha channel (or vice verse for fully visible).

I think I just answered my own question! :)

I should probably just RTFM, but I assume I can have an 8bpp paletted sprite with alpha?

Thinking about it, I could maybe have a “darken” pixel as black, with the alpha channel controlling how much to darken that pixel. A “lighten” pixel would be white (again with the alpha channel controlling how much). And pixels that don’t affect the destination would be fully transparent in the alpha channel (or vice verse for fully visible).

That would work, although the lightening operation would be a blend towards white, rather than applying a >1 multiplier to the RGB. I guess it depends whether that’s what you’re after or not!

The other option I can think of would be to have two sprites (one to brighten, one to darken) and use EOR plotting to invert the screen before (and after) plotting the brightening sprite. If my maths is right this would result in the brightening sprite effectively performing a blend of destrgb = destrgb+destrgb*srcalpha if white is used for the pixel colour.

I should probably just RTFM, but I assume I can have an 8bpp paletted sprite with alpha?

Yes, the RISC OS Select alpha mask format can be used for that. Each pixel will have its own alpha value, independent of the palette index.

The other option I can think of would be to have two sprites (one to brighten, one to darken) and use EOR plotting to invert the screen before (and after) plotting the brightening sprite

Interesting thought. I’d need to switch to banked screens but I’ve been getting the feeling that’d be needed anyway for what I’m mulling over.

With the amount of reading & writing of screen memory needed for that approach, you’ll probably find you can get better performance by creating a temporary sprite in main memory each time you want to plot your brightening/darkening sprite. Which wouldn’t be as bad as it sounds, considering that you’ll be able to optimise the last EOR rectangle plot into an EOR sprite plot:

1. Use OS_SpriteOp 16 to create a sprite from the area of the screen you’re interested in
2. Plot the darkening sprite to the temp sprite
3. EOR plot to invert the temp sprite
4. Plot the brightening sprite to the temp sprite
5. EOR plot the temp sprite to the screen

Depending on the other things you need to do, this may alleviate the need to use multiple screen banks. Or you could even use main RAM for your second screen bank and just use OS_SpriteOp to blit it to VRAM once you’re done.

Which wouldn’t be as bad as it sounds, considering that you’ll be able to optimise the last EOR rectangle plot into an EOR sprite plot

Scratch that – I was thinking there’d be a “dest = NOT src” plot action, but there isn’t. But I think using an offscreen buffer will still end up being faster than reading & writing directly to screen memory, at least for the Iyonix. And if you wanted to it wouldn’t be too hard to put together your own plotter to copy the inverted sprite back to the screen – it’ll just be a simple rectangle of pixels.

I think I just answered my own question! :)

You did, that is the way to do it.

That would work, although the lightening operation would be a blend towards white, rather than applying a >1 multiplier to the RGB

That IS a lightening operation. What you’re describing is a (clipping) saturation process.

EOR is a red herring, Steve’s approach is correct… except for gamma correction of course (everyone mimes “broken record”).

I think using an offscreen buffer will still end up being faster than reading & writing directly to screen memory, at least for the Iyonix

A single alpha blend onto the screen should not require any more screen IO than using a separate buffer would, though a separate buffer then needs its own IO. Alpha blending isn’t doing a pixel at a time is it?!

A single alpha blend onto the screen should not require any more screen IO than using a separate buffer would

I was still talking in the context of doing a saturation process with the EOR plotting. Although I guess it’s possible a separate buffer would still be faster for the single sprite op case.

Alpha blending isn’t doing a pixel at a time is it?!

For complex plots screen reads/writes are performed one word at a time, which for 32bpp would obviously end up being one pixel at a time. I think this is partly due to limitations in how registers are allocated (it’s easier to guarantee the system will work if it just sticks to one register). Plus the code subscribes to the mantra of “screen memory is slow” and so it avoids redundant reads/writes wherever possible, so isn’t very easy to get working with LDM/STM.

I have in the past gone to extreme lengths to ensure screen writes took place in aligned two-word (or four-word) bundles (and from instructions on four-word boundaries!), but modern core architectures don’t really benefit from that kind of ARM OCD ASM IYSWIM.

but modern core architectures don’t really benefit from that kind of ARM OCD ASM IYSWIM

Try telling that to Ben…

We all need a hobby. Mine is failing to learn Japanese.