A question on rotosprite / rotozoomsprite

[bigsofty]

Can you post your test code please?

[Kryten]

Code (glbasic) Select Expand

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.

[Kryten]

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.

[spacefractal]

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.

[MrTAToad]

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?

[spacefractal]

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.

[Kryten]

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.

[MrTAToad]

I wouldn't be surprised if an odd size causes problems - don't know what would cause it though...