Yay!
I, of course, have done nothing

As soon as http://www.riscosopen.co.uk/ goes live, I'll get cracking

how are you getting on?

R/B swap  Use main RAM  Use DMA  FPS
Yes       Yes           Yes      33
Yes       Yes           No       25
Yes       No            -        9
No        Yes           Yes      41
No        Yes           No       25
No        No            -        30

Have you looked at the red/blue colour swapping in PicoDrive 0.11? It might be faster.

Have you looked at the red/blue colour swapping in PicoDrive 0.11? It might be faster.

In PicoDrive enabling colour swapping will take no extra time at all - because it's done in the pre-existing function that converts from 12bpp to 16bpp/32bpp.

One word now you've got an Iyonix, ...

PLD

I tried using that. It made one function 10% slower

Also note that it PLD on memory that can't be cached does nothing, which on RO really means video RAM and any device memory mapped by the PCI module in practice.

Screen memory is not cached

Lastly, you have a graphics chipset on the other side of the pipe which is much more capable of drawing things vertically

Also note that it PLD on memory that can't be cached does nothing, which on RO really means video RAM and any device memory mapped by the PCI module in practice.

*pciinfo on my nVidia reveals that the memory is prefetchable, and it seems to perform like it's cacheable. Is this some new feature for OS 5.12/new cards, or has it always been like it?

Well, I don't know how to use it, do I?

That's just the info reported in the PCI config registers, and without checking I'm not sure whether you're looking at the BAR for the video memory or the registers/ROM.

Why do you think that prefetching and cacheing screen contents is beneficial in plotting code at >=8bpp anyway? Are you blending into the existing image rather than overwriting? :-s

Well, I don't know how to use it, do I?

Strangely enough, the best way to use it is to invoke the OS plotting routine since that provides a mechanism for device-specific acceleration code to step in and perform the plotting faster

I was looking at the second 'memory' one. But I'm not even sure if that's the right one - OS_ReadVduVariables suggests the screen memory is at &DC900000, and none of the ranges displayed by *pciinfo cover that.

At the moment, it only gets as complex as rending images with a 1bpp mask. But I may have a go at blending/lighting if I can get this code running fast enough

Ah, but how much of that comes with RISC OS 5, and how much is added by Geminus?

Then you're honestly better off testing the mask and writing out the appropriate pixels than reading, merging and writing back.

but my point is simply that if you're not about to write your own hw acceleration code then that's your best hope of getting good performance.

If you're plotting large sprites

Have you considered using the approach taken by doom instead? Rather than using a 1bpp mask you could try runlength encoding the images. ie you store runs of solid pixels and runs of transparent ones so you can skip over the transparent ones quickly. This does, of course, not work so well for images using dithered solid and transparent pixels but I suspect you're not using them as they don't deal with scaling very well to say the least.

but my point is simply that if you're not about to write your own hw acceleration code then that's your best hope of getting good performance.

Assuming that what I'm trying to draw can be done using OS_SpriteOp, that is. And I doubt OS_SpriteOp is fast enough for the RiscPC version

If you're plotting large sprites

Map tiles are 64x64, 16bpp.