Hi,
I want to display the video stream in the irrlicht engine, but I don't know how to implement this properly.
First thing in my mind is to use Draw2DImage, but this method requires an ITexture format. I look up the
defination of the ITexture and I don't know how to set the image buffer to an ITexture instance directly.
I can only find this way to achive my goal: first step save the image buffer to a disk file, then load the
image file via getTexture API. It works but makes me feel stupid.
So can you help to display the video stream more efficiently?
ITexture is somewhat platform dependent. You can get the color format with ITexture:: getColorFormat (). Notice that the names there are based on old Direct3D api names... so red and blue might be switched in memory (you'll see in the result... explaining that is a longer story that involved loading files from disk without having to switch byte order - one day I'll go over it and document it better).
To access the data use ITexture::lock() which returns a byte-block. It's size is ITexture::getPitch() (for width used in memory) times ITexture::getSize().Height. You only have to write ITexture::getSize().Width bytes per line (difference between width and pitch are filler-bytes some sytems use - you need to regard them for the calculation of your pixel but don't have to set them).
If you use Irrlicht svn trunk developer version (instead of Irrlicht 1.8) you should currently set IVideoDriver::setTextureCreationFlag(irr::video::ETCF_ALLOW_MEMORY_COPY, true) before creating that texture as it will be slow for this case otherwise (we might set that back as default for Irrlicht 1.9 as well, but haven't decided yet - the other default optimízes for the case where textures never change).
CuteAlien wrote:ITexture is somewhat platform dependent. You can get the color format with ITexture:: getColorFormat (). Notice that the names there are based on old Direct3D api names... so red and blue might be switched in memory (you'll see in the result... explaining that is a longer story that involved loading files from disk without having to switch byte order - one day I'll go over it and document it better).
To access the data use ITexture::lock() which returns a byte-block. It's size is ITexture::getPitch() (for width used in memory) times ITexture::getSize().Height. You only have to write ITexture::getSize().Width bytes per line (difference between width and pitch are filler-bytes some sytems use - you need to regard them for the calculation of your pixel but don't have to set them).
If you use Irrlicht svn trunk developer version (instead of Irrlicht 1. you should currently set IVideoDriver::setTextureCreationFlag(irr::video::ETCF_ALLOW_MEMORY_COPY, true) before creating that texture as it will be slow for this case otherwise (we might set that back as default for Irrlicht 1.9 as well, but haven't decided yet - the other default optimízes for the case where textures never change).
Thanks for your reply!According to your reply, I think these are necessary steps: first of all create an IImage, then use this IImage to create a ITexture by addTexture, after that use IImage::lock() to get the data pointer, and fill the data with video buffer. Finally unlock the data pointer and the ITexture is filled with video buffer. Am I right?
You don't need an IImage. You can directly create a texture with IVideoDriver::addTexture. And ITexture has a lock() function - don't go over IImage - otherwise you ahve to create textures constantly from the IImage which would be slow.
Basically ITexture is closer to the hardware. IImage is an intermediate step which makes some things easier (like loading from file), but in your case you don't really need it.
CuteAlien wrote:You don't need an IImage. You can directly create a texture with IVideoDriver::addTexture. And ITexture has a lock() function - don't go over IImage - otherwise you ahve to create textures constantly from the IImage which would be slow.
Basically ITexture is closer to the hardware. IImage is an intermediate step which makes some things easier (like loading from file), but in your case you don't really need it.