Irrlicht Engine

The front buffer copy used by Irrlicht to get screenshots is intentionally slow going by the Direct3D docs. In practice, it takes about 800 milliseconds. In RakNet, I'm introducing a new feature which continually grabs the backbuffer and sends it to a remote server for video recording. In my own application, this only takes 1 millisecond.

The code is here:
http://raknetjenkinsso.svn.sourceforge. ... iew=markup

I'd like to ask for a feature to be added to Irrlicht for a fast backbuffer copy to main menu. It should take as inputs the output size to downsize to (using CopyRect) and should return the row pitch.

This way I can add real-time video recording as a feature to the Irrlicht demo that comes with RakNet, which would be an awesome showcase for users of my new application.

Screenshots are made from front buffer, don't know if this also applies to front buffer. However, we'll also add more general buffer copy methods which will allow for the described optimizations in the next version at least.

Did those new copy methods get added to 1.7.3? To copy from the backbuffer? Looking for a fast way with the opengl driver to copy the backbuffer, or rectangles of it, to a texture...

You should render your scene to a texture in the first place, grabbing from a backbuffer is slower and more convoluted.

I think there are some functions in the drivers, but not yet exposed and generally applicable.

@hendu: works fine under d3d, got 500 fps with simple scenes, and 120 fps with complex env-mapped scenes. Just want to do the same in opengl.

@hynrid: any ideas what they might be called/found?

Wouldn´t code like this do it, and translate into efficient video memory copy, as both FB and texture are in vid memory already?

glBindTexture(GL_TEXTURE_2D, target_texture )
// Copy rect To The Texture
glCopyTexSubImage2D(GL_TEXTURE_2D, 0, x1, y1, x2, y2, Width, Height);

In directX9 you have the stretchrect function to grab the framebuffer, and copy it to a texture, (this allows for instance antialiased postproduction), it is definately faster than the screenshot grabbing way, and i have the impresion that OpenGL has something similar, though i haven't found it yet nor have tested its functionality (Pixel buffer objects?)

yeah, that´s what I´ve implemented for the d3d driver, it works fast and well, but in opengl, I´ve used glcopysubtex... or whatever its called, and it works, but I get about 12 fps only.

opengl seems to lack any direct video memory blt functions, so i´m not sure if fast memory ops are possible without using some opengl extender...

I´d sort of like opengl to be allround better than d3d, but... PBO may be faster than glCopytexsub... but still need to be loaded with the FB, so still a big overload on the stretchblt function, that is if I didn´t miss something out there...

I know AMD/NVidia have some video frame extensions for fast video transfer to textures, but it all seems a bit "cloudy"; will the NVidia extensions work on amd GPU´s too, and visa versa?...

this opengl thread covers the same issue, if anyone is interested http://www.opengl.org/discussion_boards ... Gl-texture

and here is a detailed paper on texture copy issue from NVidia, with how to select the memory formats to avoid byte "swizzling" conversions: https://developer.nvidia.com/sites/defa ... download=1