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?
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.
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.
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.
Rotating a sprite around its centre is very useful, and much better than rotating from around a corner and then repositioning...
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).
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.
Srarch for pivot. I did such a function once. Many years ago
http://www.glbasic.com/forum/index.php?topic=1457 there
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.
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 :-)
Its probably due to the use of floating-point values - it adds imprecision (or could just be an optical illusion).
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.
finally managed to test on a couple of different PCs - with the same result - so it would appear to be an issue in GL.
Maybe my texture mapping is one pixel too far to the right and bottom on the polyvector use...
Can you post your test code please?
GLOBAL tank
GLOBAL esc
tank=1
SETTRANSPARENCY RGB(255,0,128)
LOADSPRITE "tank47a.bmp",tank
SETSCREEN 800,600,1
//mainloop
WHILE esc=FALSE
drawscreen()
SHOWSCREEN
WEND
FUNCTION drawscreen:
DRAWLINE 101,100,101,220,RGB(0xff, 0xff, 0x40)
DRAWLINE 145,100,145,220,RGB(0xff, 0xff, 0x40)
DRAWLINE 95,105,220,105,RGB(0xff, 0xff, 0x40)
DRAWLINE 95,141,220,141,RGB(0xff, 0xff, 0x40)
SMOOTHSHADING FALSE
DRAWSPRITE tank,100,100
ROTOSPRITE tank,100,160,0
ROTOZOOMSPRITE tank,160,100,0,1
ENDFUNCTION
using the attached image (but as a .bmp)
Interestingly, if you load it as a png without the transparency you can see the image is offset a little.
and a screenie demonstrating the above.
measuring both the right hand and lower images, it would appear that the image size is the same (47 pix each side for the pink bit), however its offset to the left and upwards, and the actual graphic image of the tank is bigger by 1 pix wide & high.
that is due you use 47x47 pixels as source. Its can been issue on some graphics card and happens here as well. Im think its a opengl issue, not glbasic issue, and the source you using is not a 2 power of two, why the graphics card have read them as 48x48 pixels instead.
So you need resize it to 48x48, put the tank in the center and use that instead. Its might work better. Im tried that with 64x64 and there its look correctly.
Howovoer im have not tested its same happens with POLYVECTORS yet.
Quote from: Kryten on 2013-Jun-27
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.
No, I meant that the rotation system would use floating-point values, which would add imprecision. Are you using SMOOTHSHADING FALSE or TRUE?
He have not even rotated or zoomed it and im confirm here too.
I'm have tried with both true and false as well on smoothshading on his code (which was set to false on the picture).
I'm thinks its limit on the graphics driver you hit, due 47x47 is not a common size....
It's a bug, but its a bug, that can't been fixes, due limits.
Quote from: MrTAToad on 2013-Jun-27
No, I meant that the rotation system would use floating-point values, which would add imprecision. Are you using SMOOTHSHADING FALSE or TRUE?
Ah, that makes things clearer :-) Thanks MrT.
Done some additional testing, and it seems to affect any image with a single pixel in the dead centre (i.e. 47 x 47, 27 x 13, 51 x 51), and the same effect on an ATI card, Nvidia Geforce card, and a laptop integrated one which I cant recall the make of.
So either its an OpenGL issue (in which case, blurgh), or as HK said, the texturemapping is off slightly on the routines for the roto commands.
Hopefully this gives enough info for him to say one way or the other.
I wouldn't be surprised if an odd size causes problems - don't know what would cause it though...