Problems with taking screenshots

[Squarefox]

Hi,

I have a problem with taking screenshots in my game.
Wherever a billboard or any other transparent object is, the screenshot is rendered correctly,
but there where the cave is (uses a custom shader), nothing is drawn:

Correct:


Incorrect:


Can anyone help me please?

Kind regards,
Squarefox

[Squarefox]

The problem occurs only with the OpenGL renderer, not with the DirectX 9 renderer.

[hendu]

Sounds like a buggy driver.

[Squarefox]

I don't think, that this is a problem with the driver. I tested it under Windows 7 with AMD and under Windows 8.1 with Nvidia and Intel HD.
The problem stays the same.

[Squarefox]

I found the error. My custom shader has written an alpha value of 0, so OpenGL dumped the cave with alpha = 0. That's why it was not visible.

Now I have some other problem: My HUD writes with alpha 0.5 (drawRectangle), so it looks a little bit wrong in the screenshot.
Is there a possibility to deactivate alpha writing in Irrlicht, when drawing images and rectangle directly with the video driver?

Kind regards,
Squarefox

[REDDemon]

I think you can easily harcode in the engine that by changin 1 line in OpenGL driver (note that rendering to texture will be affected!). I think you can even call the opengl function your self before doing part of the rendering (if you need to have that enabled/disabled).. Of course, those stuff I'm suggesting to you is terrible XD and on the long run will hurt you

[CuteAlien]

IVideoDriver::draw2DImage has a parameter for alpha. I think so do most other direct drawing functions in IVideoDriver (most pass SColor which has an alpha value). For stuff in the scene you use materials - some of them are without alpha.

[Squarefox]

I use alpha values != 255, so that isn't the problem. The problem is that they overwrite the alpha on the previous rendered stuff, so the screenshot is not correct at this parts of the image (the screenshot is partly transparent there).
Can I use materials also for 2D stuff?

[hendu]

That is how it works. You can disable alpha writing for some nodes if needed, or process the image to remove the alpha channel, or save to a non-alpha format like bmp or jpg.

[Squarefox]

I tried:

Code: Select all

 
VideoDriver->enableMaterial2D(true);
irr::video::SMaterial& mat = VideoDriver->getMaterial2D();
mat.ColorMask = irr::video::ECP_RGB;
 

which should set the color mask to RGB only for 2D boxes, but they are still transparent.
Does the 2d material not work with the color mask or what I am doing wrong?

[Squarefox]

I fixed the problem in an other way now.
VideoDriver::writeImageToFile has a parameter param. This is not used for png writing.
I now adapted the png writer, so that it does a conversion from RGBA8888 to RGB888 when param is 1.
Now the screenshots look correctly.

If needed, I can provide a patch for Irrlicht, so that this feature is in the upcoming releases.

But I have one further question:

Code: Select all

void CColorConverter::convert_A8R8G8B8toR8G8B8(const void* sP, s32 sN, void* dP)
{
    u8* sB = (u8*)sP;
    u8* dB = (u8*)dP;
 
    for (s32 x = 0; x < sN; ++x)
    {
        // sB[3] is alpha
        dB[0] = sB[2];
        dB[1] = sB[1];
        dB[2] = sB[0];
 
        sB += 4;
        dB += 3;
    }
}
 
void CColorConverter::convert_A8R8G8B8toB8G8R8(const void* sP, s32 sN, void* dP)
{
    u8* sB = (u8*)sP;
    u8* dB = (u8*)dP;
 
    for (s32 x = 0; x < sN; ++x)
    {
        // sB[3] is alpha
        dB[0] = sB[0];
        dB[1] = sB[1];
        dB[2] = sB[2];
 
        sB += 4;
        dB += 3;
    }
}

In the color converter RGB and BGR seems to be flipped (see code). But the conversion works as the function name tells.
Can anyone explain me that RGB<->BGR flip?

[CuteAlien]

I'm as confused as you - especially if this is really working.

edit2: Ugh - I got the explanation. It's because Irrlicht used the same names as D3D9 which had that messed up. So it was just a name there - not describing the memory format (no joke). See https://msdn.microsoft.com/en-us/librar ... re_formats
This is pretty ugly - especially without any documentation about it. But how to fix this without breaking software... (well I can document it at least).

edit3: I've added a comment in the docs.
I think the reason likely was that this was the format used in bitmap files. Then DX file-loaders loaded the rgba values with a single 32-bit values on a little endian machine flipping the byte order. But they kept the name to have the same name as in the file. MS changed the names in DX10 by the way.