Add RSP command to offset position of all other draw commands

[lmcd]

I'm writing a 2D compositor using libdragon to make complex 2D UIs, and I occasionally run into a bottleneck whereby too many draw calls are issued (e.g. rendering lots of text). I've found that using blocks can dramatically reduce overhead, but In most cases, I'm unable to encapsulate with rspq_block, as the drawing is only happening when the text is moving - so the positions of everything are changing each frame, which invalidates the block.

It would offer a pretty substantial performance win in this use case, if I could issue a simple one-line call to set the origin of all subsequent draw calls - that way everything could be baked into blocks and I'll only need to adjust the origin when things are moving.

Even if this only applied to rdpq_texture_rectangle, and rdpq_fill_rectangle, I think this would be well worth the effort.

[rasky]

We do have rdpq_xform API that was meant for that. We would need rdpq_text to use it (maybe as an opt-in?) and more importantly, its implementation should be moved to the RSP.

[lmcd]

I think something more generalized across draw commands would be great, as I could quite heavily pivot my entire 2D compositor to blocks, which could reduce a lot of load. I'm not really using rdpq_text to render anymore, except to generate the rdpq_paragraph_t, which I'm then transforming into another type to save memory.

The majority of my renderer is just higher level abstractions on top of rdpq_texture_rectangle, rdpq_texture_rectangle_scaled and rdpq_fill_rectangle. For some scene transitions, I could even encapsulate an entire view hierarchy into a block and offset the entire UI (comprising many labels and various other UI components) at once, all within a block.

[lmcd]

Also, I'm sure it's something you've thought about (any maybe intersects with magma, I'm not sure), but I also envision a situation in which blocks can be compiled offline into programs that allow you to directly tweak parameters in memory at runtime. So the block memory offsets for parameters like prim_color or whatever could be captured, with a higher level API to inject these parameters into the 'program'/block at runtime before handing off the block memory location to the RSP.