Van B wrote: "I was wondering how I should use pixelmaps and images though, hopefully you can point me in the right direction."
Pixelmaps are a tool for manipulating an image in an RGBA8 format, reminiscient of DBPro's image memblocks.
As you have discovered there are currently no means of updating an image from a pixelmap, you can only create new images from them. This is an oversight on my part and I should add such updating functionality to them in the future. They may also receive an auto-convert functionality between various pixel formats instead of being locked to B8G8R8A8_UNORM as they currently are.
In any case, what you would do is indeed to recreate the image. You can keep and change the same pixelmap, so you don't have to recreate that one however. This is in fact how the engine's "labels" work behind the scenes so it is quite efficient even with the constant image deletions / recreations.
What I imagine you're missing is that after creating the new image you also have to reapply it to anything using it (DX11 SET OBJECT TEXTURE / DX11 SET SPRITE IMAGE / etc.). This is so because you are indeed creating a
new image. Another implication of this is that you should delete the old image too, instead of just overwriting its address, or else you will leak memory and probably end up with a crash within seconds if you're doing the pixelmap -> image thing in every frame.
Van B wrote: "... I wonder if there's a way to just update the image without deleting it."
Indeed there is, though this is a bit more low level than the pixelmap approach.
Using
DX11 LOCK IMAGE you can lock and update an image in-place. This furthermore allows you to only lock a subset of the image, such as a certain mip level or array slice, or indeed a rectangle that is smaller than the image itself.
After that you would call
DX11 GET IMAGE PIXEL BUFFER POINTER to get a raw memory pointer into the pixel data of the image. You can use
DX11 GET IMAGE PIXEL BUFFER SIZE,
DX11 GET IMAGE PIXEL BUFFER WIDTH and
DX11 GET IMAGE PIXEL BUFFER HEIGHT to query the accessible memory area. After that it is up to you to manipulate / read this memory as you see fit. What the data in the pixel buffer actually represents depends on the image's format (which can be checked using
DX11 GET IMAGE FORMAT) and for some formats such as compressed ones or things like R10G10B10A2 or R16_FLOAT it would be a bit of a braintwister to set these accordingly, especially using DBPro. It certainly is possible though.
However, assuming you have a BGRA8_UNORM image, as you would if you created it from a pixelmap in the first place, the data layout is pretty straight forward. Every set of four bytes would be a new pixel, where the first byte is the blue channel, the second the green, the third the red and the fourth the alpha channel for that pixel. Once you're done editing the image you would simply unlock it (
DX11 UNLOCK IMAGE) and the source image will be updated accordingly, without any need to reapply it to objects / limbs / sprites / what-have-you.
Finally there is a third option of using a render target image and updating it using shaders instead.
This could either be done through a pixel shader as a normal rendering operation, or using a compute shader, which would allow you to only write to certain pixels and also to read the previous pixel data already present in the image. Doing it this way offers the highest possible efficiency as no stalling communication between the CPU and GPU is required (image data is held in VRAM and has to be copied into RAM for access from the CPU when using pixelmaps or locking an image, and then back to VRAM again when done), however the tradeoff is that it is (usually) more complicated to set up as well.
Also thanks for the stickying of this thread, whoever did that! Most honorific
Though I've got to admit I got worried it had been deleted for a while there before finding it in green on the top of the thread list
