HELP- i just want to draw an image over and over and over

[digijohnny]

I have an IImage i need to display every frame, this image needs to to be modifiable, i use IImage setPixel.

now i just want to display this on the screen some where. the only method is VideoDriver->draw2Dtexture().
so i need to make a texture from this image, the only method... VideoDriver->addTexture(name,image)
now i have just allocated a whole new texture object and image data every frame, even if i use the same name....wtf
at 30 fps on an iPhone this gives me about 2minutes before i run out of memory. the image is only 64x64.

so ..... how do i change image data for a texture without allocating a whole new texture??

if i drop() this texture before the next time i exec texture=addtexture() the app crashes, Documentation says don't drop if using add methods, only drop when using create methods

so whats the best way to draw dynamic image data to the screen, why isn't there a VideoDriver->Draw2DImage() method, there are methods for drawing lines and pixel, why does this have to be so complicated, I understand if you intend to use this image as a 3D UV mapped texture the GPU must get in the mix, i just want to blit copy a 2d image to the screen
i could just draw this pixel by pixel with image->getPixel(x,y) and VideoDriver->drawPixel(x,y), but thats just ridiculous overhead calculating offsets and addresses every pixel read/writel ..128x128 pixels cuts the frame rate from 30 to 3fps

to avoid the standard replies of "Well.... Why do You Want To Do That?"
the answer is ... its complicated
the image data is actually the result of a custom noise generator used to seed a voxel engine to generate realtime clouds. the end result does not need to show the image at all, but i need to see the 2d image data in real time while developing/testing for the noise generation and cloud propagation functions.

[hybrid]

The intention is not so strange, nor is this technique in general. Which is, why there is a simple way. Maybe consult the API first next time...
Both IImage and ITexture have a method lock(), which gives you access to the raw image data. You can alter also texture data that way, and after unlock() have the new data on the GPU, ready for rendering. You should probably disable mipmaps on that texture, and add a write-only flag so texture data is not downloaded to CPU again each frame.
And in case you need to get rid of a texture, there's a removeTexture call in the driver, which will free the memory of the texture data

[chronologicaldot]

I didn't know this, so I looked it up quick:
If you're working with the Burnings driver, the texture (given in files labeled CSoftwareTexture2) just holds an IImage (in the CImage array MipMap). It returns an array of u8 (which is what's in SColor and directly assignable to it).
If you're working with DirectX, it's harder. The files CD3D8Texture.h and the corresponding .cpp file are where you look. That texture is a wrapper for an IDirect3DTexture8 (or 9, depending on what DirectX you want).
I'm sure OpenGL has something different.
Seems like using Burnings would be your best bet for ease.

Now, if you want OpenGL with Burnings, you could always create two IrrDevices, but that's memory intensive.

[hybrid]

The difference between IImage and ITexture is basically the storage location. IImage is stored in CPU RAM, while ITexture is stored in GPU RAM. Since software drivers will always render on the CPU, there is no need (not possibility) to store things in GPU RAM. Hardware accelerated drivers need this, though, so you can only render things which are already on GPU RAM there. Otherwise it gets really slow (e.g. via setPixel). But since the interface is pretty relate, you really only need the lock/unlock methods and you can work on any image and texture the same. Just remember that in any case the change of the content will happen on the CPU (unless you use shaders to alter your texture) and thus quite a lot of data is transferred between GPU and CPU. This happens for the software drivers as well, though, as in the end sw render results will also be transferred to GPU to show the actual framebuffer image on the screen.

[Granyte]

An other option would be to move your noise generation algorithm to the gpu and use the same texture as render target each time as a bonus your noise generation will go much faster