[rlgl] Custom blend mode with one function call

[veins1]

Right now setting custom blend mode requires two function calls: rlSetBlendFactors() and rlSetBlendMode.
I imagine instead of doing rlSetBlendFactors to store the factors and rlSetBlendMode to apply them, just having something like rlSetBlendModeCustom where you pass blend factors and it just applies them. There's no reason for user to just store them, like, there's no situation where a user might do a bunch of rlSetBlendFactors without rlSetBlendMode.
The rlSetBlendMode function stays pretty much the same and the new way of setting custom blend mode will also be just one function call, instead of two.

[raysan5]

I've been reviewing this issue. Here a recap of current implementation:

• rlSetBlendFactors()/rlSetBlendFactorsSeparated(): Store blending mode factors but does not apply them.
• rlSetBlendMode(mode): Apply a pre-defined blend mode, in case of RL_BLEND_CUSTOM/RL_BLEND_CUSTOM_SEPARATE, apply the stored factors. It also guards the re-applying of an already applied blend mode, for performance cost concerns.
• BeginBlendMode()/EndBlendMode(): Wraps rlBlendMode() call on raylib side. It is done this way because OpenGL pipeline state-changes that require issuing a draw call (and force batching) are wrapped in Begin*()/End*() statements.

As per mi understanding, the proposed addition would be a function like:

void rlSetBlendModeCustom(int glSrcFactor, int glDstFactor, int glEquation)
{
    rlDrawRenderBatch(RLGL.currentBatch);
    glBlendFunc(glSrcFactor, glDstFactor); 
    glBlendEquation(glEquation);
}

In this case, if this function is called in the middle of a drawing process, despite the factors could have not changed, the pipeline is stalled, a draw call is issued and the blendind states are set again, implying a performance cost.

There is also the separate blend factors option, probably a new separate function should be added for it but same issue will happen.

there's no situation where a user might do a bunch of rlSetBlendFactors without rlSetBlendMode.

Actually there is. In my tools I set the factors for a custom blend mode at initialization and later in the loop I can just enable/disable the custom blend mode as desired.

Personally I neither like that rlSetBlendFactors()/rlSetBlendFactorsSeparated() require OpenGL specific input parameters, afaik are the only functions in raylib that do not abstract those parameters.

What is your proposed redesign considering this explanation?

[veins1]

I will talk about rlSetBlendModeCustom only, but everything applies to rlSetBlendModeCustomSeparate, since they are almost the same.
Essentially, what I see rlSetBlendModeCustom do is this:

//This is not an implementation, just showing roughly what it does compared to existing code
void rlSetBlendModeCustom(int glSrcFactor, int glDstFactor, int glEquation){
  rlSetBlendFactors(glSrcFactor, glDstFactor, glEquation);
  BeginBlendMode(CUSTOM);
}

The current functionality of checking if the factors are changing is preserved. We check and if they are different we store and apply them immediately.

I think of this function as being a replacement of rlSetBlendFactors, not an additional function.

Maybe this looks silly, since everyone can just add this function to their own code, but to even write this function one needs to open source code to see that just calling rlSetBlendFactors is not enough, a call to BeginBlendMode is required. And again, one needs to look at source code to see that BeginBlendMode has to come after rlSetBlendFactors, not before.

Most importantly, I think, it allows an easy switch from using pre-defined modes with BeginBlendMode to using custom modes with rlSetBlendModeCustom without anything unexpected happening.

[raysan5]

@veins1 I'm afraid that solution is not possible, BeginBlendMode() belongs to rcore module and rlSetBlendMode() should belong to rlgl that does not depend on rcore. Also, if that function was somewhat moved to rcore it would expose at raylib level internal OpenGL values that should be defined and exposed to users, breaking the abstraction and increasing considerable the complexity.

Sincerely, I prefer to keep the approach as it is, despite the users have to call two functions to set the custom blend factors.

[veins1]

As I wrote in the comment to the code, that was not intended to be viewed as implementation, but rather as an example of what functionality it would have. Just substitute rlSetBlendMode instead of BeginBlendMode.

Any change made is exclusively inside rlgl. No changes to core and no dependency on core required.

This is what the real implementation looks like roughly:

void rlSetBlendModeCustom(int glSrcFactor, int glDstFactor, int glEquation){
#if defined(GRAPHICS_API_OPENGL_33) || defined(GRAPHICS_API_OPENGL_ES2)
    if ((RLGL.State.currentBlendMode != RL_BLEND_CUSTOM) ||
        (RLGL.State.glBlendSrcFactor != glSrcFactor) ||
        (RLGL.State.glBlendDstFactor != glDstFactor) ||
        (RLGL.State.glBlendEquation != glEquation))
    {
        rlDrawRenderBatch(RLGL.currentBatch);

        RLGL.State.currentBlendMode = RL_BLEND_CUSTOM;
        RLGL.State.glBlendSrcFactor = glSrcFactor;
        RLGL.State.glBlendDstFactor = glDstFactor;
        RLGL.State.glBlendEquation = glEquation;

        glBlendFunc(RLGL.State.glBlendSrcFactor, RLGL.State.glBlendDstFactor);
        glBlendEquation(RLGL.State.glBlendEquation);
    }
#endif
}

[raysan5]

I reviewed it again and I got to the conclusion it adds an extra amount of duplicate code just to simplify a function that can be very easely implemented at user side with currently provided functions:

void rlSetBlendModeCustom(int glSrcFactor, int glDstFactor, int glEquation)
{
    rlSetBlendFactors(glSrcFactor, glDstFactor, glEquation);
    rlSetBlendMode(RL_BLEND_CUSTOM);
}

Similar function with separate factors can also be added at user side, no need to be part of rlgl.