Hằng số 0,009215689 đại diện cho cái gì?

Tôi liên tục thấy điều này bật lên liên tục trong các tệp tiêu đề đồ họa khác nhau

0.0039215689

Nó dường như có một cái gì đó để làm với màu sắc có thể?

Đây là lần truy cập đầu tiên trên 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

Con số này thể hiện điều gì? Tại sao không ai tuyên bố nó là một const?

Tôi không thể tìm thấy bất cứ điều gì trên Google đã giải thích nó.

0.0039215689 xấp xỉ bằng 1/255 .

Thấy rằng đây là OpenGL, hiệu năng có lẽ rất quan trọng. Vì vậy, có thể an toàn để đoán rằng điều này đã được thực hiện vì lý do hiệu suất.

Nhân với đối ứng nhanh hơn chia nhiều lần cho 255.

Lưu ý bên:

Nếu bạn đang tự hỏi tại sao tối ưu hóa vi mô như vậy không để lại cho trình biên dịch, thì đó là vì nó là một tối ưu hóa dấu phẩy động không an toàn. Nói cách khác:

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

do lỗi làm tròn điểm nổi.

Vì vậy, trong khi các trình biên dịch hiện đại có thể đủ thông minh để thực hiện tối ưu hóa này, chúng không được phép thực hiện trừ khi bạn nói rõ ràng với chúng thông qua cờ trình biên dịch.

Liên quan: Tại sao GCC không tối ưu hóa a * a * a * a * a * a thành (a * a * a) * (a * a * a)?

Phép nhân này bằng cách 0.0039215689fchuyển đổi cường độ màu có giá trị nguyên trong phạm vi 0 đến 255 thành cường độ màu có giá trị thực trong phạm vi 0 đến 1.

Như Ilmari Karonen chỉ ra, ngay cả khi đây là một sự tối ưu hóa thì nó cũng được thể hiện khá tệ. Nó sẽ rõ ràng hơn nhiều để nhân lên (1.0f/255).