The new Sprite format with alpha channel

How does one actually use these sprites?

How can I make one from a PNG, and then plot it to the screen?

Very vague questions I know, but I’ve hunted for docs etc. and cannot find a thing. I can plot a sprite fine, and I can convert from PNG to sprite, but not with alpha channel.

How can I make one of these new-fangled sprites?

Chers

Garry

Plotting an alpha channel/alpha mask sprite is easy (use any of OS_SpriteOp 52, 56 or 65 with bit 3 of R5 set). But creating them is a bit trickier as the sprite editing tools are lagging behind the OS a bit.

• RISC OS 5 Paint: Doesn’t fully support editing of alpha sprites yet. Will probably come as part of a bounty at some point
• RISC OS Select Paint: RISC OS Select sprites with alpha masks will work fine with RISC OS 5. But obviously you’ll need a copy of Select.
• ChangeFSI: Although it was recently updated to add support for PNG import, it doesn’t look like it supports importing the alpha channel. I’m not sure how much work would be needed to get that implemented, so far ChangeFSI hasn’t had any updates to allow it to work with the new sprite formats.
• NetSurf: If you load a PNG with alpha into NetSurf and then export it as a sprite it’ll have alpha data. But you’ll need to manually edit the sprite mode word in order to change it from a standard RISC OS 3.5 format sprite to one of the new RISC OS 5 sprites.
• Spr2Png: It looks like this might be your best bet, as it supports RISC OS Select alpha sprites. However I haven’t tried it myself so I can’t guarantee that it’ll work. I.e. it might be trying to perform an OS version check before allowing you to create an alpha sprite. (Note I’ve had to tinyurl the URL due to textile getting in a right mess over the domain name containing a -)

Also if you’re using a Raspberry Pi you’ll need to be running the latest development ROM – support for the new screen modes & sprite formats hasn’t made it into the beta RC releases yet.

Re: Spr2Png: I’ve just given this a go (and double-checked the sources) and it looks like it doesn’t support export of RISC OS Select alpha sprites. However it can create RISC OS 3.5 format sprites with the alpha data hidden in the unused byte, the same as NetSurf. So if you manually change the sprite mode word (from &301680B5 to &78608051) then that will get you a RISC OS 5 ABGR sprite.

I should probably take a look at ChangeFSI and see how hard it would be to get it to export sprites with alpha (and whether it breaks horribly when loading new format sprites!)

I should probably take a look at ChangeFSI and see how hard it would be to get it to export sprites with alpha (and whether it breaks horribly when loading new format sprites!)

When looking at the PNG stuff I did prototype something to hook out the data, but then I realised ChangeFSI didn’t deal with transparency for those formats it could already load (at a glance this would implicate native sprites, GIFs, PCX, BMP) so decided to stick to opaque handling.

I’m not sure conceptually how to scale an image with a 1bpp mask and know what to do when scaling the mask. With alpha levels it’s easier to think of the mask as a greyscale image which just needs scaling same as any other. Maybe 1bpp just gets a dithered mask?

But coming back to the quoted text, I’d wager currently some love is needed loading some of the newer format sprites, as does the printing system.

but then I realised ChangeFSI didn’t deal with transparency for those formats it could already load

Ah. This task suddenly became a lot more complicated!

I’m not sure conceptually how to scale an image with a 1bpp mask and know what to do when scaling the mask. With alpha levels it’s easier to think of the mask as a greyscale image which just needs scaling same as any other. Maybe 1bpp just gets a dithered mask?

Yeah, that’s a bit of a tricky one.

I think one approach which will work equally well for 1bpp masks and alpha masks is to weight the contribution of the RGB values by their alpha component. That way masked out pixels (which may have funny values in their RGB channels) won’t affect the resulting outcome. For the alpha channel you can just average out the values as normal. And then apply whatever dithering you wish for 1bpp mask output.

But coming back to the quoted text, I’d wager currently some love is needed loading some of the newer format sprites, as does the printing system.

Well the good news is that ChangeFSI does throw a sensible error if you ask it to load a sprite format it doesn’t understand, and it looks like adding support for the new RGB formats should be pretty straightforward. It’s only alpha (and masks in general) that will be a headache.

I think one approach which will work equally well for 1bpp masks and alpha masks is to weight the contribution of the RGB values by their alpha component.

I must apologise for jumping in here without reading up on how you’ve been implementing the new sprite types, but I’m wondering, did you go for premultiplying the RGB components by the alpha component? By which I mean, for example, does colour &80808080 encode semi-transparent white rather than semi-transparent grey?

It’s quite common these days for cross-platform graphics libraries to use premultiplied alpha. It’s computationally simpler when compositing more than two things together because there’s no need to renormalise the RGB components after each pairwise composite, and it would mean that you can treat the four colour components in a planar manner when scaling an image. It also allows for the encoding of luminous objects by setting one or more RGB component higher than the corresponding alpha (though that does mean that you’re committed to doing saturated adds).

Jeffrey, Ben, and Sprow, thanks a lot.

I guess my first move is to update to the latest version of RISC OS on my Pi and take it from there.

My ultimate aim will require converting PNG to Sprite as part of my program, so drag and drop solutions are fine for testing, but not my requirement in the long term. Spr2Png is likely to be the way forward for me.

Thanks a lot, will look at updating my Pi right now.

Cheers

Garry

OK, I’ve copied in a new ROM enough times into the Loader folder inside !Boot to realise I’m doing something wrong.

My version of RISC OS seems stuck at 5.19, even thought I’ve copied in 5.21.

What am I missing here?

Cheers

Garry

Sorry, spoke too soon. I gave up on using RISC OS to put on the new ROM, and used my PC, worked first time!

I think one approach which will work equally well for 1bpp masks and alpha masks is to weight the contribution of the RGB values by their alpha component.

I must apologise for jumping in here without reading up on how you’ve been implementing the new sprite types, but I’m wondering, did you go for premultiplying the RGB components by the alpha component? By which I mean, for example, does colour &80808080 encode semi-transparent white rather than semi-transparent grey?

No, they’re just regular alpha blended images.

The new sprite formats only really exist because the OS needed support for writing to the new framebuffer formats. And as far as framebuffer formats go, regular alpha seems to be more widely supported than premultiplied alpha.

Support for premultiplied alpha formats would be a nice goal for the future, but it isn’t in my current plans.

Garry: At a guess – did you copy or move the ROM file?

The Loader directory is a very clever fudge – it’s actually a different partition on the SD card, but the OS thinks it’s just a directory within Filecore. I would hazard a guess that RISC OS doesn’t spot the difference and would think a file move is like a file move within Filecore, not a copy across two different partitions. For that reason I’m a little ultra-paranoid with regards to the contents.

Also you must make sure that the filename for the new ROM image is identical to its predecessor.

The routine I usually use is:

1) Backup your SD card – I used to use a spare SD card reader for this; now I use an X100 board on my Pi which offers a spare slot.

2) Copy the current ROM into the root directory.

3) Delete the current ROM image in the Loader directory (copy + delete rather than move).

4) Copy the new ROM image into place.

5) Rename it so that it is exactly the same name as the old ROM image.

6) Reboot.

7) Test for a few days – if stable, then replace the backup (cycle a couple of cards so you can revert the changes if needs be).

William, I copied from the root of my SD card into the Loader folder, renamed the old ROM, and then renamed the new ROM to ‘RISCOS/IMG’. Perhaps the problem was caused by me having 2 ‘Loader’ folders, one in the backup of my old !Boot structure?

Anyway, it seems to be OK now, so I’ll persevere with will trying to plot an alpha-blended sprite.

You should never try to copy or move ‘Loader’ Bad things happen.
You should be able to copy the whole contents or individual files.

So when I followed this guide:

https://www.riscosopen.org/wiki/documentation/show/RISC%20OS%20Upgrade

Which suggests renamed the old !Boot folder, is that OK? !Boot contains Loader of course.

No that guide will not work on a Pi. It needs updating.

Also on any system I don’t recommend doing step one “Move your existing !Boot aside” until after you have the new !Boot de archived into a subdirectory.

It needs updating

…when you get it to work, Garry…¹ and if you have the time!

Keep at it!

¹ I’ve not followed this exact procedure myself for some time now, otherwise I’d update it myself.

Try rebooting and if it doesn’t work, fix it

This involves downgrading the SCL to a version before the scanf fix so that !Writer on an Iyonix still works. Not sure this is a good policy or that most users will understand this correctly. This seems to work as nothing seems to RMEnsure the later SCL yet.

I’d be happy to help out with documenting this sort of thing, but I guess without being totally confident in what I’m doing, I wouldn’t want to give people duff advice.

I think fiddling with the Raspberry Pi’s FAT32 partition on the PC seems like it’s pretty solid, but that does not help people without PCs.

I’d be happy to help out with documenting this sort of thing, but I guess without being totally confident in what I’m doing, I wouldn’t want to give people duff advice.

Generally all help is gratefully received! Why not give it a try and post your revised text here?

My thought would be to have separate instructions for systems¹ with ‘Loader’ partitions

@Chris E
On the subject of loader partitions, I seem to recall that you wanted a 32 bit safe GuardDD module (as per the old PC card software)
Is the module that only guards against deletion of DOS Directory objects¹ > 2Mb sufficient or does it need extra functionality to stop the specific files in the object being deleted/renamed when accessed from RISC OS?

¹ As it stands it would protect against removal of the whole directory/partition from the RO side, but not against deletion of the files within like the RISCOS.IMG file

but not against deletion of the files within like the RISCOS.IMG file

Needs an override *command in order to allow legitimate system upgrades not to fail in unexpected ways…

Remember that any techniques you come up with to protect the Loader partition will be mostly obsolete once the current filesystem bounty is complete and we get proper partition support.

Remember that any techniques you come up with to protect the Loader partition will be mostly obsolete once the current filesystem bounty is complete and we get proper partition support.

No techniques, quick fiddle with the module source which almost anyone could do. That covers the basic protect, more work for the files inside, but that’s more akin to the Recyclone / Blackhole stuff.
Of the three Recyclone is the one where I don’t have a 32 bit version. The GuardDD is a small part of Sprow’s “intellectual exercise”, which actually involves reverse engineering parts to create source to play with.

It’s not about time spent except as a learning experience. Hopefully it teaches me more than just how awkward these things can be.