ColourTrans_GenerateTable

I have a problem with ColourTrans_GenerateTable in combination with a mode 27 sprite without palette.

My code:

// create color translation table
regs.r[0]=area;           // sprite area
regs.r[1]=(int)name;      // sprite name
regs.r[2]=-1;             // for current mode
regs.r[3]=0;              // default for mode
regs.r[4]=(int)table;     // ptr to buffer
regs.r[5]=1<<4;           // generate large table if 16/32 bpp mode
regs.r[6]=0;              // no transfer workspace
regs.r[7]=0;              // no transfer function
_kernel_swi(ColourTrans_GenerateTable,&regs,&regs);

If I give this sprite a palette with !Paint, all works fine.

ColourTrans version is 1.95 (29. May 2016)

What I’m missing?

This is normal. The default colours in a 16 colour mode are for the lower eight to be the black, red, green, yellow, blue, magenta, cyan, and white. The upper eight are flashing colours, but since this doesn’t make sense in a sprite, it’ll look like duplicates of the first eight.
See PRM page 1-560.

It’s a historical thing, based upon how the old Beeb used to work (MODE 2).

So in WIMP environment to plot such a sprite by OS_SpriteOp 52 I have to check first the sprite details and build the WIMP palette myself?

Is there any SWI to ask the WIMP for the palette in mode N? I see none.

Not just that, but you’ll also need to take the scaling into account, or things may go amusingly wrong in 2:4 pixel modes.

Look at https://www.riscosopen.org/wiki/documentation/show/Wimp_ReadPalette and https://www.riscosopen.org/wiki/documentation/show/Wimp_ReadPixTrans.

PS: You don’t get the palette in MODE n, you get the current palette. It’s supposed to be mode independent, at least, that’s the idea.

Doesn’t Wimp_PlotIcon sort all this guff out for you?

Wimp_PlotIcon is not the first thing that comes in mind while digging throu the PRMs.
Thanks for the hint.