A question on rotosprite / rotozoomsprite

[Kryten]

Ive come across an interesting occurrence when displaying a sprite using the commands drawsprite, rotosprite and rotozoomsprite, and Im wondering if its a bug, as intended, or if anyone else has come across the same issue. Unfortunately I cant post a screenie as Im a bit limited for time at the moment.

Basically, I have a sprite that is 47x47 pixels, which would give a single pixel in the exact dead centre.

Using drawsprite, it draws at the correct size (47x47)

Using rotosprite it draws but is increased in size by 1 pixel in both height and width (so 48x48), so there would be a block of 4 pixels in the middle and the centre would be where the 4 middle pixels join.

Using rotozoomsprite results in the same as rotosprite.

Drawing the same image on screen at the same time using the 3 different commands shows this quite clearly.

Now, I havent had the time to check to see if this is just an issue on my PC (but the gfx drivers are bang up to date), and it occurs on both V10 and the V11 GLB versions.

So, Im somewhat perplexed as to why this would be and was wondering if anyone has an explanation, as I would have thought it would be easier to rotate around a central pixel than a theoretical intersection point of 4 pixels?

[spacefractal]

either its a floating issue, or elsewise its a "power of 2" issue (etc some graphics card, if not all, often "convert" textures using "power of 2", hence you see that issue.

Not sure its a glbasic issue, but howover im have fighting with a similar issue as well with zoomsprite, so im dedicated to uses POLYVECTOR to replace that instead. Here its mightbeen somewhere more complicated.

[Kryten]

I know its not a float issue as Ive made sure everything is rounded to an integer. I was guessing that it might be a power of 2 issue though. Must try it on the parents laptop when I get 5 mins :-)

Cheers spacefractal, glad to know Im not the only one to come across it. a little frustrating, but not insurmountable.

[spacefractal]

but hotspot its calculated from the center and not from the top/left. That giving out own issues as well. Im have never ever liked that! There is allways some loss of precision due that. Last time im saw the tiled background overlapped a another background, all just due the annoying center hotspot. Howover POLYVECTOR can property can been used for rotated sprites, bot more math is required. Im have only used its for none rotating thing.

Its a loss of precision issue, but im dont think its can been fixed at all.

[MrTAToad]

Rotating a sprite around its centre is very useful, and much better than rotating from around a corner and then repositioning...

[spacefractal]

im have never liked it. im have allways some issues with its, howover its more zoomsprite, not rotozoomsprite. Im more prefer doing calculation the center by my self from top/left.

Here im thinks its a similar issue with precision, which me thinks should not been happens with top/left as hotspot, which was with zoomsprite (which required me to use polyvector instead).

[Slydog]

It would be a nice touch if Gernot could add a pivot point setting per sprite.  Then you can set the pivot point to the top-left if it makes your coding easier, or center for rotating, etc.

But for this issue (heck, for any sprite commands), I would use custom polyvector routines for displaying and rotating my sprites.  In addition to a speed boost, another advantage is you could implement sprite sheet / texture map features, to keep all your sprites in one file.  Plus you can implement custom pivot points.  May be overkill for starting with GLBasic, or a simple game, but once done you can reuse it in the future.

[Kitty Hello]

Srarch for pivot. I did such a function once. Many years ago

[Kitty Hello]

http://www.glbasic.com/forum/index.php?topic=1457 there

[spacefractal]

im uses that functions in Greedy Mouse and now in Karmamiwa. We still sometime seen a pixels placement wrong, when the original hotspot is in center. So its would been better and easier (for me), if its was top left. Im think if that was integrated, then Kryten could have been better control over the command.

[Kryten]

My original question wasnt re hotspots tho (although thats a useful topic in itself) by the fact that an odd sized sprite was drawn bigger when using the roto commands :-)

[MrTAToad]

Its probably due to the use of floating-point values - it adds imprecision (or could just be an optical illusion).

[Kryten]

Nope on both counts - attached is a screencap (doubled up for clarity). Ive made sure that all variables are integered, and Im not using any scaling (so value of 1).

The top left image is the original, right is drawn with rotozoomsprite, and bottom left with rotosprite.

Interestingly, if the image is drawn with zoomsprite (same values), theres no issue - so it would seem to be related to the rotation commands.

[Kryten]

finally managed to test on a couple of different PCs - with the same result - so it would appear to be an issue in GL.

[Kitty Hello]

Maybe my texture mapping is one pixel too far to the right and bottom on the polyvector use...