ctr wrote:I think you're right. I was confused because SDL renders bitmaps correctly (e.g. the beeb output), and the font is just a bitmap, but the font was coming out wrong. But, as you say, bitmaps rendered through SDL_RenderGeometry aren't using the same code. So it makes sense.
So is this a deliberate feature of SDL? Is there a rationale to why SDL_RenderGeometry is different? or might this be a bug in SDL? If the latter would it make more sense to temporarily work around it in the embedded version of SDL and submit upstream?
My repo is the upstream :-| - the RenderGeometry stuff was originally an OS X-and-Linux-only patch attached to a bug report, to which I added Windows D3D9/D3D11 support. Then I uploaded it to a github... I get the impression that official SDL isn't interested until it has a software renderer, so that is probably its home for now.
But you're quite right about RenderGeometry, of course. The rationale for having it pass the data straight through, unprocessed, was that this was sort of its spec (insofar as it has one) - but really it might as well just add the offset when appropriate, since it's probably the right thing to do for virtually all (or more) probable uses.
I can add a toggle to switch it off.