상수 0.0039215689는 무엇을 나타 냅니까?

다양한 그래픽 헤더 파일 에서이 지속적인 팝업이 계속 나타납니다.

0.0039215689

아마도 색과 관련이있는 것 같습니다.

다음은 Google 의 첫 번째 히트입니다 .

void RDP_G_SETFOGCOLOR(void)
{
    Gfx.FogColor.R = _SHIFTR(w1, 24, 8) * 0.0039215689f;
    Gfx.FogColor.G = _SHIFTR(w1, 16, 8) * 0.0039215689f;
    Gfx.FogColor.B = _SHIFTR(w1, 8, 8) * 0.0039215689f;
    Gfx.FogColor.A = _SHIFTR(w1, 0, 8) * 0.0039215689f;
}

void RDP_G_SETBLENDCOLOR(void)
{
    Gfx.BlendColor.R = _SHIFTR(w1, 24, 8) * 0.0039215689f;
    Gfx.BlendColor.G = _SHIFTR(w1, 16, 8) * 0.0039215689f;
    Gfx.BlendColor.B = _SHIFTR(w1, 8, 8) * 0.0039215689f;
    Gfx.BlendColor.A = _SHIFTR(w1, 0, 8) * 0.0039215689f;

    if(OpenGL.Ext_FragmentProgram && (System.Options & BRDP_COMBINER)) {
        glProgramEnvParameter4fARB(GL_FRAGMENT_PROGRAM_ARB, 2, Gfx.BlendColor.R, Gfx.BlendColor.G, Gfx.BlendColor.B, Gfx.BlendColor.A);
    }
}

//...more like this

이 숫자는 무엇을 나타 냅니까? 왜 그것을 const로 선언하지 않는 것입니까?

Google에서 설명하는 내용을 찾을 수 없습니다.

0.0039215689대략 같습니다 1/255.

이것이 OpenGL임을 알면 성능이 중요 할 것입니다. 따라서 이것이 성능상의 이유로 수행되었다고 추측하는 것이 안전 할 것입니다.

역수를 곱하면 255를 반복해서 나누는 것보다 빠릅니다.

사이드 노트 :

왜 그러한 마이크로 최적화가 컴파일러에 남아 있지 않은지 궁금하다면, 그것은 안전하지 않은 부동 소수점 최적화이기 때문입니다. 다시 말해:

x / 255  !=  x * (1. / 255)

부동 소수점 반올림 오류로 인해.

따라서 최신 컴파일러는이 최적화를 수행하기에 충분히 똑똑 할 수 있지만 컴파일러 플래그를 통해 명시 적으로 말하지 않으면 수행 할 수 없습니다.

관련 : GCC가 a * a * a * a * a * a를 (a * a * a) * (a * a * a)로 최적화하지 않는 이유는 무엇입니까?

이 곱셈은 0.0039215689f0에서 255 범위의 정수 값 색 강도를 0에서 1 범위의 실제 값 색 강도로 변환합니다.

일 마리 카로 넨 (Ilmari Karonen)이 지적했듯이 이것이 최적화라고해도 다소 잘못 표현 된 것입니다. 를 곱하는 것이 훨씬 더 명확합니다 (1.0f/255).