Copying a texture from one RenderTexture to another

[SoulBlade]

Hello,

I feel bad about posting another question so soon, but again, after a whole lot of experimentation and an inability to find information on the topic, I find myself back here for help.

Let's say you have 2  identical RenderTextures, renderTexture and renderTexture[~b].  Both have the same transformations applied to them, let's say, for examples sake, 2.0f zoom factor.  When you draw a sprite with renderTexture's texture onto renderTexture[~b] with a sprite of origin 0,0 and position 0,0, it will draw the sprite at transformed scale (since zooming is the only transformation applied).

In order to combat that, let's say you setScale the sprite to 2.0f.  Logically this would seem to work, but when you offset the sprite it seems some precision is lost in the transformation.  I will post some example code to illustrate the problem:

Code: [Select]



//Example code showing the transference of the texture
//Keep in mind that each RenderTexture has a view applied which
//has a zoom of 2.0f
//buffer variable is a bool
//handleTexture variable is a pointer to ~b's texture
renderSprite.setOrigin(0, 0);

renderSprite.setScale(2.0f, 2.0f);

//Offset by 32 pixels
renderSprite.setPosition(32.0f, 0);
renderSprite.setRotation(0.0);
renderSprite.setTexture(*handleTexture, true);
renderTexure[buffer].draw(renderSprite);

                buffer = (buffer ? 0 : 1);



My gut tells me it may have to do with some floating point math truncation in the computation of the transformation, but I could just be doing something totally stupid and just need a fresh perspective to point it out.  Thank you!

[Groogy]

Exactly what is it that you want to copy to the other texture? The visible appearance of the texture(texels+transformations) or do you want to only copy the data(texels)?

Keep in mind if you copy the raw data over to the other texture and then after apply the same transformations you will get an identical result.

[SoulBlade]

The texture ALREADY has all the transformations, you see?  So if I copy the texture over, it applies the transformations a second time.  I switched over to using the SFML transforms, and frankly, I'm not sure how to directly reverse the effects so that when the transforms are applied again a second time they are correct.  

An easier method would be to avoid the transformations all together and apply the texture without transformations.

So to answer your question, I'm transferring the texels + transformations, primarily because it's the only method I know of/can find for SFML.  The result being a transfer of texels + transformations + transformations, which I want to avoid, because it seems there is a loss of precision when using the internal conversions.

[SoulBlade]

I believe I found the issue.  I make the scaling variable, and I compared that variable to the result of this:

Code: [Select]


renderTexture[buffer].convertCoords(1, 1) - renderTexture[buffer].convertCoords(0, 0)

The conversion deviates from the variable at it's 100th and 1000th places, a significant deviation when you have large scaling factors being applied.  I'm investigating the issue further.

[SoulBlade]

Alright well I am officially stumped on this problem.  

After further experimentation, I seem to be copying the texture just fine.  If I wasn't, the texture would spiral downward or upward in size because of the rapid back and forth transfers.  This is not happening, and the image is stable.

When I offset the texture, however, the coordinates don't seem to match up.  And there is absolutely no pattern that I can recognize.  It doesn't seem to be a floating point issue, either, as I used whole numbers for all the values and it still has a precision issue.  Sigh.

UPDATE:  At close zooms, the offset seems to function properly.  At larger zooms, it functions properly only at certain values.  This is definitely indicative of a floating point error.  I'm just not sure where it originates from -- I can't seem to find any errors in that regard within my code.  

I'm changing all the values in SFML's transform code from floats to doubles to see if that fixes the problem...I'll update with the result.

[SoulBlade]

The issue of precision was a non-issue.  Additionally I converted the system to manually transform instead of relying on the view transformations and, unfortunately for me, had the exact same result as allowing the views to handle the transformations.

I'm stumped, but as for the topic of this thread, copying the texture was not the issue since I achieved the same result with view transformations and manually applying transformations.  Which naturally is indicative that the texture copying I had implemented worked properly. So I suppose the matter is closed, since I imagine this is now an issue of transforms.


UPDATE:

Problem solved!  The issue was that float-precision is not saved on a per-pixel basis it seems.  So I would offset the image with float precision, and (I believe) it truncates it to integer precision.  This would cause some noticeable deviation from the properly transformed position after enough small-iteration translation.  I feel pretty dumb, because I made a stupid assumption to begin with.  Anyway, ensuring the deviation is always an integer value makes sure there is no discrepancies.  I apologize for making a thread to begin with, considering it's all been me talking to myself.  Hopefully this is helpful to someone.

[JohnB]

you could just use memcpy