Sprite Plotting - part 4

In this article, I will explain how to collect information from existing sprites and tackle VDU driver redirection on and off sprites located in user sprite areas (USAs).

Use of information about sprites

In some cases, rather than build a new sprite from scratch, you want to do it from an existing one by copying it within the same USA, for example. To calculate the required size to set the Extra-BufferLength_byte% value (see previous article), you simply need to get the information from the sprite to be copied. Again, there is no special "OS_SpriteOp" command that provides direct information about sprite size. You can use two commands "OS_SpriteOp 37" and "OS_SpriteOp 40" to collect information from an existing sprite:

"OS_SpriteOp 37" returns the size of the palette when you do R3 = -1. Size is not in bytes but apparently in number of logical colours. I just ignore whether it is a bug or not.

"OS_SpriteOp 40" returns:

Unfortunately, when you want to add a palette to a sprite, information about palette size is of no help since the palette isn't created yet.

Basic program ModifyPal (supplied on Archive monthly disc):

"ModifyPal" works also on 256 true-colour palette sprites by adding the palette to a blank sprite created in mode 28 (arbitrary mode). Bit 31 of R3 is set when executing command "OS_SpriteOp 37". Other 256 pseudo-colour sprite modes such as 10, 13, 15, 21, 24, 32, 36, 40, 47 and 49 would work as well. As a matter of fact with RISC OS 3, such routine is a neat alternative to Basic program "Create256" proposed in my first article.

In some cases, the added palette isn't the same as the one you would get when building the sprite with Paint. I have no explanation for this.

I have noticed that the previously proposed routines FNDetermineSpriteImageSize() and FNDetermineSpriteMaskSize() weren't working properly for sprite modes 2, 4, 5 and 10, where you need more bytes per pixel line than expected from the pixel depth for some unknown reason. Now I am using the ratio LineLength_byte% / Line-Length_pixel% from the screen equivalent mode and applying the ratio to the sprite to be created, rounding first the calculated number of bytes then the number of words. It works in all modes.

VDU drivers and "OS_SpriteOp"

I will finish this article by clarifying the effect of VDU driver redirection on "OS_PlotOp" commands. The PRM is very poor in this respect and therefore it can easily become very confusing for users because source or destination are redirected depending of which command it is.

Redirection of VDU driver on and off sprites is necessary to handle some tricky sprite operations normally involving screen video memory. It can be done either on sprite image data or sprite mask data. For now, I will just tackle sprite image data as the redirection target. The schedule on the following page summarises all the necessary information on the impact of redirection on some particular "OS_SpriteOp" commands after redirection compared to normal action.

For the sprite reference supplied as normal input data in R0 and R1 of the "OS_SpriteOp" commands, I use the following notations:

Redirection on and off sprite image data is achieved with "OS_SpriteOp" command 60. To restore screen VDU, you just need to execute the same command again with the R0, R1 R2 and R3 registers values as they were initialised when first switching the output to sprite.

"OS_SpriteOp" commands 2 and 3 are of no real interest whereas "OS_SpriteOp" commands 14 and 48, assuming implicit cursor position values, aren't really practical in Wimp applications.

All other "OS_SpriteOp" commands 34 and 49 through to 53 will involve Sprite_k in USA_l designated as the VDU output. However, it can affect source or destination target.

Basic application !Redirect16 (supplied on the Archive disc):

The source sprite must have no mask, otherwise scrap data present in the sprite image data corresponding to mask transparent pixels will show in the destination sprite and be initialised through the construction process of the sprite.

Basic application !Redirect34 (supplied on Archive disc):

Both sprites are built in the same native mode as no mode compatibility check is done when executing the command. Sprite "sprite0" has a mask whether sprite "22" has none.

Basic application !Redirect51 (supplied on Archive disc):

Arbitrary values have been selected to fill CharacterToSpriteScale Array as the PRM doesn't provide clear information about it.

I have added two other very important commands to the schedule:

They will also be affected by redirection. I will use them next time.

Now we know how to handle multiples USAs and to involve sprites as VDU targets in different sprite operations. Next time, we will be ready for real plot action on sprites, taking into account both source and destination modes.


Source: Archive Magazine 14.4
Publication: Archive Magazine
Contributor: Daniel Moyne