[Renderers] Add ability to negotiate capabilities with the renderer

[EmmanuelMess]

If the renderer is incapable of showing 3D textures, or drawing specific elements, like some colors (for example monocrome interfaces), clay should be able to take that into account, and inform the final user. This would probably become more important if new rendering commands are added to simplify the rendering.

[EmmanuelMess]

Also, hover might not be available on devices with no cursors (touchscreens, SoC connected to a screen).

[nicbarker]

This is a really interesting idea, do you have a particular approach in mind that you're envisioning?

[EmmanuelMess]

This is a really interesting idea, do you have a particular approach in mind that you're envisioning?

Linux allows programs to negotiate capabilities with drivers (I could only find this implemented for cameras, but I think its implemented for other drivers too), so the idea comes from there. If I were to do it, I would make the user pass renderer generated (probably gigantic) configuration struct to clay on initialization (in linux its done with bitsetting via ioctl).

typedef struct Capabilities {
    bool hasCursor;
    bool hasMeshImplementation;
	bool hasScissor;
} Capabilities;

// In renderer
void RendererName_GetCapabilities() {
	return (Capabilities) {
		.hasCursor = false,
		.hasMeshImplementation = false,
		.hasScissor = true,
		//etc
	};	
}

void main() {
	//...

	Capabilities cap = RendererName_GetCapabilities();
	Clay_Initialize(..., cap);
	//...
}

[VisenDev]

Why not use bitflags for this?

#define RENDERER_CAPABILITY_CURSOR  1<<0
#define RENDERER_CAPABILITY_SCISSOR 1<<1
#define RENDERER_CAPABILITY_MESH    1<<2
#define RENDERER_CAPABILITY_COLOR   1<<3
//etc

#define STANDARD_RENDERER_CAPABILITIES \
    RENDERER_CAPABILITY_CURSOR  | \
    RENDERER_CAPABILITY_SCISSOR | \
    RENDERER_CAPABILITY_MESH    | \
    RENDERER_CAPABILITY_COLOR    

int main() {
    int renderer_capability_flags = STANDARD_RENDERER_CAPABILITIES;

    printf("%d\n", renderer_capability_flags);
    return 0;
}

[EmmanuelMess]

Why not use bitflags for this?

It is easier to "miss" stuff when doing bitflags as compared to structs IMO. Leaving a bit turned off is easier than leaving a field blank in a struct when filling it.

[FintasticMan]

At least use bitfields in the struct then for packing. (And then the end result will—in theory—be identical to setting bits like suggested anyway)

[EmmanuelMess]

At least use bitfields in the struct then for packing. (And then the end result will—in theory—be identical to setting bits like suggested anyway)

There could be a way to allow the compiler to pack the entire struct into a set of unsigned ints, if your concern is for optimization.

[FintasticMan]

Exactly, my suggestion is to define the struct like this:

typedef struct Capabilities {
    unsigned hasCursor : 1;
    unsigned hasMeshImplementation : 1;
    unsigned hasScissor : 1;
} Capabilities;