Using OS_SpriteOP 52 for colour conversion

Does anyone have an example of using OS_SpriteOp 52 in conjunction with ColourTrans_GenerateTable to plot sprites from any MODE to the current MODE?

I believe I’ve followed the documentation, but OS_SpriteOp generates an Abort trying to execute non-existent code in the RMA. The ColourTrans_GenerateTable call generates a 3 word table, 1st and 3rd words are “32K+” which is the source Sprite bpp and the 2nd word appears to be a pointer into the RMA which OS_SpriteOp is calling, but there’s no code there. I’m guessing you can’t simply pass the buffer from ColourTrans_GenerateTable as R7 in OS_SpriteOp? Or I’ve simply misunderstood the documentation.

I’ve got some test code at home which I can dig up if necessary. In the meantime, there’s some general information here.

From the description of your crash, it sounds like you’re setting bit 7 of R5 when calling OS_SpriteOp, which enables use of a Colour Mapping Descriptor. If you’re using a table generated by ColourTrans then you need that bit to be clear.

sounds like you’re setting bit 7 of R5

That was indeed the problem, thanks.

Next problem…how do I use ColourTrans_GenerateTable to generate a table from a 16 entry palette I pass to it? Or is there a way to plot a 16 colour sprite with another palette using OS_SpriteOp that I’ve missed?

Next problem…how do I use ColourTrans_GenerateTable to generate a table from a 16 entry palette I pass to it?

The clue is on the wiki page :-)

R0 = source mode / sprite area
R1 = source palette pointer / sprite

So instead of passing in the sprite area + name/pointer in R0/R1 you just need to pass in the mode number of a 16 colour mode (or the mode word of your 16-colour sprite) and a pointer to your custom palette (and make sure that bit 0 of R5 is zero so ColourTrans knows you’re giving it a mode+palette combo)

The required palette format is described here

Since you’re using a custom palette you’ll also want to make sure bit 4 of R5 is clear when calling OS_SpriteOp, to make sure OS_SpriteOp doesn’t ignore your translation table.

The clue is on the wiki page :-)

Again, I followed the documentation, but there’s no clear code examples. It results in random colour translation on every plot.

The code I’m using is:

MODE "X640 Y480 C16M EX1 EY1"
DIM P% 64
P%!0=0
..
P%!60=&BBGGRR00
SYS "ColourTrans_GenerateTable", 12, P%, -1, 0, 0, 0 TO ,,,,S%
DIM colourtrans% S%
SYS "ColourTrans_GenerateTable", 12, P%, -1, 0, colourtrans%, 0
SYS "OS_SpriteOp", 52+256, sprites%, S$, X%, Y%, 0, 0, colourtrans%

Try setting the “wide” flag for ColourTrans + OS_SpriteOp (R5 bit 4 for ColourTrans, R5 bit 5 for OS_SpriteOp). Otherwise I think ColourTrans will look at the destination BPP, go “don’t be silly, you don’t need a translation table for true-colour modes” and return you nothing. For a regular sprite this works fine (OS_SpriteOp / SpriteExtend will use the sprite palette directly) but if you’re using a custom palette then you’d want a way of forcing the conversion.

I’ll update the wiki to state that sometimes ColourTrans won’t return a table.

Try setting the “wide” flag for ColourTrans + OS_SpriteOp (R5 bit 4 for ColourTrans, R5 bit 5 for OS_SpriteOp)

Forcing “wide” doesn’t appear to make any difference:

MODE "X640 Y480 C16M EX1 EY1"
DIM P% 64
P%!0=0
..
P%!60=&BBGGRR00
SYS "ColourTrans_GenerateTable", 12, P%, -1, 0, 0, 1<<4 TO ,,,,S%
DIM colourtrans% S%
SYS "ColourTrans_GenerateTable", 12, P%, -1, 0, colourtrans%, 1<<4
SYS "OS_SpriteOp", 52+256, sprites%, S$, X%, Y%, 1<<5, 0, colourtrans%

EDIT: I’ve figured a workaround, by creating a new sprite.

Going back to the 32K conversion for a minute, it doesn’t appear to account for transparent pixels when you plot using OS_SpriteOp 52 with colour conversion.

Going back to the 32K conversion for a minute, it doesn’t appear to account for transparent pixel when you plot using OS_SpriteOp 52 with colour conversion.

Define “transparent pixel”. Does the sprite have a mask or an alpha channel? Are you setting bit 3 of the OS_SpriteOp flags?

I’ll take a closer look at the custom palette issue when I get home, it sounds wrong for it to not be working at all.

Your sample code works fine for me, both with and without wide translation tables (Iyonix with RISC OS 5.24, and a Pi 1 with a recent-ish dev build)

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

5.24????

5.22, sorry.

Rats. I thought we had a news scoop :-)

5.24????

One of the tasks en-route to a stable release is completing the User Guide for RISC OS 5. In the UK, and elsewhere, we have a long bank holiday weekend in hand – so volunteers can get involved by either:

• Picking an unclaimed chapter, claiming and updating it
• Reviewing an already completed chapter for errors and noting the corrections

There’s been phenomenal progress so far with 42 chapters amounting to 600+ pages done, but the weight has fallen on the shoulders of just 5 contributors (one of which is ROOL!).

Define “transparent pixel”. Does the sprite have a mask or an alpha channel? Are you setting bit 3 of the OS_SpriteOp flags?

I’ll check later. It was using OS_SpriteOp 34 which I switched to 52 thinking it would do the same thing but with colour conversion, if only it were that simple! I’m modifying an unreleased RiscPC game, so it can be released for modern machines, which was using a 32K resolution. I’ve upped it to 16M and am now going through correcting the sprites that don’t plot correctly.

Your sample code works fine for me, both with and without wide translation tables

I thought I’d coded correctly! Last night I figured out why it was failing, hidden away in the code it was switching to a 16 bit MODE, then capturing a Sprite. It was this Sprite I was trying to plot; I’d double checked the Sprite on a RiscPC as I suspected it may be a bpp issue, but it was obviously a 16 colour Sprite as 4bpp MODE’s work. On the Pi the MODE was being switched to a 256 colour MODE, so ended up a 256 colour Sprite. It only contained colours 0-15, but obviously confused OS_SpriteOp when I passed a 16 colour palette for a 256 colour Sprite, regardless of which colours it used. What I did in the end was create a new Sprite with a 16 colour palette, the plot into it…problem solved and a whole day wasted on one irritating Sprite!

With your help, I’ve managed to sort out most of the Sprite bpp issues, I just have the odd resolution the game is used to resolve. It works fine on a Pi with AnyMode, but will fail on a Pi using EDID and probably most other modern machines that don’t upscale. I’ll put a “Work in Progress” video of it on the JASPP channel later.

I’ve run out of games to run under ADFFS, so figured I’d start looking at some of the source code I’ve received other the years.

I’ve run out of games to run under ADFFS, so figured I’d start looking at some of the source code I’ve received other the years.

Or even look at more open ended development? ARM on ARM, hypervisor…

You, Jeffrey, couple of weekends ;)

ARM on ARM

Sadly I think past experience has shown that if we were to work on that together we’d spend all our time arguing about which approach we think is best :-)

Sadly I think past experience has shown that if we were to work on that together we’d spend all our time arguing about which approach we think is best :-)

Some call these things arguments, some call them lively discussion.
There were things I did for the local CAMRA branch that I stopped doing when I no longer had my father to argue with and remove rough edges. (Couldn’t be mistakes, I was born in Yorkshire :))

Usually the winner in any such argument is the one who produces actual working code. :-)

Are you setting bit 3 of the OS_SpriteOp flags?

That was it, I wasn’t setting bit 3 in R5. It’s still not correct though, ColourTrans_GenerateTable is returning 0 for the table size, when I try to generate a table from 32K>16M, so I’ve still got something wrong. Here’s the code:

DIM mode% 32
mode%!0=1:mode%!4=800:mode%!8=600:mode%12=4:mode%!16=-1:mode%!20=3:mode%!24=32767:mode%!28=-1
MODE "X800 Y600 C16M EX1 EY1"
SYS "ColourTrans_GenerateTable",mode%,0,-1,0,0,0 TO ,,,,S%

ARM on ARM, hypervisor

Already done ARM on ARM in ADFFS and have ditched the Hypervisor idea as it’s not currently possible under RISCOS, without resorting to hackery.

past experience has shown that if we were to work on that together we’d spend all our time arguing

I don’t recall any arguments :| Only a very brief discussion around the different methods and their pro/cons. I’ll start a new thread, as it would be useful to come to some agreement on the best way forward.

ColourTrans_GenerateTable is returning 0 for the table size, when I try to generate a table from 32K>16M

That’s fine. Translation tables are only used for mapping to/from palettes. If both source and dest are true-colour then SpriteExtend will rely on its code generator for re-packing the RGB channels.

past experience has shown that if we were to work on that together we’d spend all our time arguing

I don’t recall any arguments :| Only a very brief discussion around the different methods and their pro/cons. I’ll start a new thread, as it would be useful to come to some agreement on the best way forward.

Sorry – I meant arguing in the friendly sense, not the mean and angry sense.

The discussion in the “What software would you like to see?” thread did start to feel like it could have gone on forever, without any real progress being made (i.e. code being written). Ultimately the best way for us to prove (or disprove) that our ideas are sound is to try implementing them. Otherwise they’re little more than unproven theories, and we’ll have a much harder time of coming to a consensus as to which is best.

Translation tables are only used for mapping to/from palettes. If both source and dest are true-colour then SpriteExtend will rely on its code generator for re-packing the RGB channels.

So I don’t need to use ColourTrans for 32K→16M provided its using OS_SpriteOp 52 to plot them?

Correct.

Correct

Hmm, I wonder why some of the 32K sprites are plotted incorrectly. I’ll have to look at them in more detail later, definitely something odd going on.