MP5 muzzle flash overlapping Created 1 year ago2022-10-05 12:02:57 UTC by Lucian

Hi,
Fire the default (non-HD) Half-Life MP5 bullet by bullet by tapping the left click in a dark room to see the muzzle flash better.
It is a "star like" flash with "5 rays" where the fifth is hidden by the tip of the gun. But sometimes you'll see two flashes superimposed on each other per click/bullet fired and slightly misaligned instead of just one.
You'll see more "rays" than normal.
An image of this can be seen here:
https://github.com/ValveSoftware/halflife/issues/3084
It looks ugly, can it be fixed?
Thanks!

The muzzleflash sprite does not undergo the same "depth hack" as weapons do, meaning it will get clipped against nearby surfaces. Weapons are rendered in a way that they're "squished" along their Z axis (assuming this axis points away from your view), which prevents them from clipping into walls.

Since the engine is in control of rendering sprites, fixing this will require some super specific workarounds, namely preventing the engine from rendering those, and rendering this stuff ourselves in mod code. I am honestly not sure how feasible that would be. At best, one would need to write some custom rendering code (whether it's using OpenGL or the engine's Triangle API) just to render these muzzleflash effects.

I'm not talking about clipping here.
I used that link to show an actual picture of muzzle flash overlapping. You see two flashes there misaligned thus more "rays" are visible.
The default muzzle flash has 5 rays in a star pattern. The overlapping produces more "rays".

Oh, I see, two muzzleflash sprites overlapping. My bad. Well, at least that should be a lot easier to fix. Could write some sorta per-frame bookkeeping/tracking mechanism that checks if a muzzleflash already happened on the current frame, so it doesn't duplicate them.

Or it doesn't rotate the sprites through an angle.
It doesn't matter if they are duplicated as long as they are perfectly aligned.

I don't think that can be done. Here's the code responsible for ordering the engine to spawn the sprites:

switch( event->event )
{
case 5001:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[0], atoi( event->options) );
    break;
case 5011:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[1], atoi( event->options) );
    break;
case 5021:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[2], atoi( event->options) );
    break;
case 5031:
    if ( iMuzzleFlash )
        gEngfuncs.pEfxAPI->R_MuzzleFlash( (float *)&entity->attachment[3], atoi( event->options) );
    break;
case 5002:
    gEngfuncs.pEfxAPI->R_SparkEffect( (float *)&entity->attachment[0], atoi( event->options), -100, 100 );
    break;
// Client side sound
case 5004:
    gEngfuncs.pfnPlaySoundByNameAtLocation( (char *)event->options, 1.0, (float *)&entity->attachment[0] );
    break;
default:
    break;
}

The R_MuzzleFlash part only accepts a position (here the attachment point on the gun), and a type, presumably the type of the muzzle flash, some sprite ID.
void ( *R_MuzzleFlash ) ( float *pos1, int type );
As you can see, there is exactly nothing there that can possibly change the angles of these muzzleflashes. It is the engine's Efx API that controls this, which is out of a modder's reach.

Yeah...it seems so...
If you have success with your proposed workaround do let me know.
Thanks!