Talk:Plan for per-vertex transformation

The Mad Cacti 05:02, 28 May 2011 (PDT):

The proposed formats include:

• 32bit argb (a8r8g8b8)
• 16bit argb (a1r5g5b5)

I don't see any need for 16 bit surfaces. In fact I'm going to re-raise my suggestion that the backend's actual surface formats be a hidden implementation detail. The engine can present either 8 bit or 32 bit pixel buffers to the backend, and the backend hands back 32 bit pixel buffers when you read a surface, but internally it can use any format it wants. For example, some devices only support up to 16 bit colour. (A backend on such a device might have to do some slow, or low quality alpha transparency calculation though.)

int gfx_surfaceStretch( pRectSrc, pSurfaceSrc, pRectDest, pSurfaceDest )

Is this a special case of gfx_renderDraw, or it is different as implied by the 'surface' prefix?

int gfx_paletteSet16( pPalette )

Why have this as a separate command instead of an argument to gfx_renderDraw?

The issue is the 16-color palette is a lookup-table into another 256-color palette. One of the workarounds suggested is to create (x + 1) * y palettes, x being the number of 16-color palettes, and y being the number of master (256-color) palettes used.

I wonder whether it's best to expose 'sprite palettes' to the backend at all. The engine could have more information about which combinations of sprite palettes and master palettes are actually used, and could handle composing the two and specifying a master palette per surface draw operation. I think the palette composing would be identical in all backends, so it would prevent code duplication to move it into allmodex.bas.

Hieran Del8 16:34, 28 May 2011 (PDT):

suggestion that the backend's actual surface formats be a hidden implementation detail.

I like the sound of that: only two formats for surfaces: 32bit, and 8bit paletted.

Is this a special case of gfx_renderDraw, or it is different as implied by the 'surface' prefix?

It's different. This operation doesn't require a device context used by OpenGL and DirectX. Beyond that, however, this stretches a rectangle over a surface. It doesn't transform the rectangle besides scaling and translation factors, which is a pretty fast blit.

Why have this as a separate command instead of an argument to gfx_renderDraw?

I was thinking the same thing... well, not about adding it to gfx_renderDraw(), but I like that idea. It will be done.

I wonder whether it's best to expose 'sprite palettes' to the backend at all. The engine could have more information about which combinations of sprite palettes and master palettes are actually used, and could handle composing the two and specifying a master palette per surface draw operation. I think the palette composing would be identical in all backends, so it would prevent code duplication to move it into allmodex.bas.

Glad you suggested that. That removes the entire duplication of headaches, keeping it in the engine. :P