hotspot different issue between STRETCHANIM and ZOOMSPRITE

[spacefractal]

STRETCHANIM does not set hotspot correctly. Instead doing center on the current frame, its does on the WHOLE picture intead. This is what it happens here. That cause the command is actuelly impossible to work with. Instead im need to work out a POLYVECTOR version of the bugged command instead.

Im will post a fix when done that.

EDIT:
This is just a simply hotspot issue which was different between ZOOMSPRITE and STRETCHANIM, how they worked. A fix is easy and possible to do. See code for ideas for this post:
http://www.glbasic.com/forum/index.php?topic=9672.msg83997#msg83997

[spacefractal]

ROTOZOOMANIM have the same issue.

[spacefractal]

look like hotspot is set on top/left, while SPRITE commands is set on the center hotspot, and only zooming is centeret? Im not sure, but its pretty much wierd and confuction when SPRITE and ANIM commands dosent do the same. Here is the result when doing this:

Code (glbasic) Select Expand


SetAlphaMode(0.25)
ROTOZOOMANIM imageID, 2, 0, 0, 0, 0.5
ROTOZOOMANIM imageID, 1, 0, 0, 0, 1
ROTOZOOMANIM imageID, 3, 0, 0, 0, 1.5
ROTOZOOMANIM imageID, 4, 0, 0, 0, 2
SetAlphaMode(1)




If you ask me, its should been placed on the cornor on the top/left screen, or a least act the same as the SPRITE commands. hotspot math is not the same.

[fuzzy70]

I don't see the problem as anything with that uses ROTO or ZOOM uses the center to do it's job which makes sense. STRETCH is different as you can scale width & height individually to fill an area rather than scale.

Otherwise imagine a asteroid sprite for example being rotated and/or zoomed, if it done that around the top left corner it would look weird & take more maths to place it where you wanted it rather than the simple (width of sprite/2) & (height of sprite/2) maths.

It would be nice if it did automatically move the modified version to the x & y of the command but the work around is not difficult.

Also I would not really class it as a bug as have seen other languages do it the same way.

Lee

[spacefractal]

It's was not really a bug, just more confuction, due hotspot is different based it's a animated draw command or not. Either it's should been center or not.

It's should a least to been documented about this.

[fuzzy70]

STRETCHSPRITE & STRETCHANIM are exactly the same in that the hotspot is the top left corner, same as DRAWANIM & DRAWSPRITE. Only the ROTO/ZOOM versions are centred.

Saying

That cause the command is actuelly impossible to work with. Instead im need to work out a POLYVECTOR version of the bugged command instead.

Im will post a fix when done that.

is indeed classing it as a bug & people reading it will think the command(s) are bugged & either look to see if it has been fixed or try to find a POLYVECTOR version of a command that works fine.

I'm sorry if i'm going a bit far with this but there are a lot of "so called bugs" reported which are not bugs at all in the forum (& this is not aimed at GLBasic forum but programming forums on the whole). Quite a few of them are either programmer error or misleading/incorrect documentation.

Lee

[spacefractal]

here is a code that fixed it. Im orignally used the same calculate for top left for STRETCHANIM as im did for ZOOMSPRITE. But for some reasons, that was not required (and yes few optomizing can been done, but not important here):

Code (glbasic) Select Expand


FUNCTION PaintImageAnim: Name$, frame, x#, y#, alpha#, zoom#, xspot, yspot, mirror=0

LOCAL h#, w#, img, hh#, ww#, xx#, yy#, SH, SW, i#, r#, animw%, animh%, orignalframeh, originalframew
IF Name$=0
img=GetStr$(Name$, "Sprites") // Just a name based sprite FUNCTION rather than number. NOT need FOR test here at all.
ELSE
img=Name$
ENDIF
GETSPRITESIZE img, w, h
IF w<1 OR h<1
DEPRINT("error in PAINTANIM(): "+Name$)
RETURN
ENDIF

originalframew=GetStr$(Name$+".w", "Anim"); animw=w/originalframew
orignalframeh=GetStr$(Name$+".h", "Anim"); animh=h/orignalframeh
w=w/animw
h=h/animh

// math placement for hotspots
IF xspot=-1 THEN PX=x#+0.5
IF xspot=0 THEN PX=ScreenWidth/2.0-(w#*zoom#/2.0)+x#+0.5
IF xspot=1 THEN PX=ScreenWidth-w#*zoom#-x#+0.5
IF yspot=-1 THEN PY=y#
IF yspot=0 THEN PY=ScreenHeight/2.0-(h*zoom#/2.0)+y#
IF yspot=1 THEN PY=ScreenHeight-h#*zoom#-y#

IF PY-PH>ScreenHeight OR PX-PW>ScreenWidth OR PY<-h*zoom*1.2 OR PX<-w*zoom*1.2 THEN RETURN 0
PW=INTEGER(w*zoom#)
PH=INTEGER(h*zoom#)

// some alpha code in that way I prefer. Not a issue in the real alphamode, its just me :-D
SetAlphaMode(alpha#)
IF mirror=1
STRETCHANIM img, frame, PX, PY, -ABS(PW), ABS(PH)
ELSE
STRETCHANIM img, frame, PX, PY, ABS(PW), ABS(PH)
ENDIF
SetAlphaMode(1)
RETURN 1
ENDFUNCTION

FUNCTION PaintImage: Name$, x#, y#, alpha#, zoom#, xspot, yspot, special=0, mirror=0

LOCAL h#, w#, img, hh#, ww#, xx#, yy#, SH, SW, i#, r#, animw%, animh%, orignalframeh, originalframew
IF Name$=0
img=GetStr$(Name$, "Sprites") // Just a name based sprite FUNCTION rather than number. NOT need FOR test here at all.
ELSE
img=Name$
ENDIF
GETSPRITESIZE img, w, h
IF w<1 OR h<1
DEPRINT("error in PAINT(): "+Name$)
RETURN
ENDIF

// math placement for hotspots
IF xspot=-1 THEN PX=x#+0.5
IF xspot=0 THEN PX=ScreenWidth/2.0-(w#*zoom#/2.0)+x#+0.5
IF xspot=1 THEN PX=ScreenWidth-w#*zoom#-x#+0.5
IF yspot=-1 THEN PY=y#
IF yspot=0 THEN PY=ScreenHeight/2.0-(h*zoom#/2.0)+y#
IF yspot=1 THEN PY=ScreenHeight-h#*zoom#-y#

IF PY-PH>ScreenHeight OR PX-PW>ScreenWidth OR PY<-h*zoom*1.2 OR PX<-w*zoom*1.2 THEN RETURN 0
PW=INTEGER(w*zoom#)
PH=INTEGER(h*zoom#)

// some alpha code in that way I prefer. Not a issue in the real alphamode, its just me :-D
IF alpha>0
SetAlphaMode(alpha#)
ENDIF
IF special=0 OR special=1
IF alpha>0 THEN ZOOMSPRITE img, PX#-((1-zoom#)*w#)/2, INTEGER(PY#-((1-zoom#)*h#)/2), PW#/w#, PH#/h#
ELSEIF special=2
IF alpha>0 THEN ZOOMSPRITE img, PX#-((1-zoom#)*w#)/2, INTEGER(PY#-((1-zoom#)*h#)/2), -PW#/w#, PH#/h#
ELSEIF special>500
IF alpha>0 THEN ROTOZOOMSPRITE img, PX#-((1-zoom#)*w#)/2, INTEGER(PY#-((1-zoom#)*h#)/2), special-1000, zoom#
ENDIF
RETURN 1
ENDFUNCTION


If you ask me, calculate top/left position after scaling should have been pretty much extractly the same for both ZOOMSPRITE and STRETCHANIM...

EDIT:
Im have renamed the subject to been more precision. Actuelly its now a just little bug, not a major.

Im not sure this bug should been fixed at all, because this might could breaks various project instead. Instead a fix could been done trought a function like this as well im highely recommered to been documented in the help file to avoid confuction for those differents.

[MrTAToad]

My PRM has a bit about hotspots for the different sprite commands - might be worth having a look.

[fuzzy70]

Think of STRETCHANIM & STRETCHSPRITE as basically a variant to polyvector. Imagine a 32x32 sprite & you wanted it to fill the screen for say a background to your high score table (crap example but shows the point)

Code (glbasic) Select Expand

SETSCREEN 640,480,FALSE
LOADSPRITE "test.png",0

// Stretchsprite version
STRETCHSPRITE 0,0,0,639,479

// Polyvector version
STARTPOLY 0
  POLYVECTOR 0,0,0,0,RGB(255,255,255)
  POLYVECTOR 0,479,0,31,RGB(255,255,255)
  POLYVECTOR 639,479,31,31,RGB(255,255,255)
  POLYVECTOR 639,0,0,31,RGB(255,255,255)
ENDPOLY

Basically the above example does the same thing, one simple quick easy command that does exactly as it's meant to (& WORKS) & same goes for the ANIM version.

Now if you wanted to do the same thing with ZOOMSPRITE then you have to start messing with maths & you might even get some rounding errors in doing so as that is not what ZOOMSPRITE (& it's ANIM brother) are suited for. Both STRETCH & ZOOM may be the same principle in that they enlarge or shrink sprites but they do it in different ways to suit different tasks.

I have just done tests with all of the sprite draw/zoom/stretch/roto commands & all of them work exactly like they should.

Also before I get flamed for my example using polyvectors & stretchsprites, it was not a comparison between the two but an illustration. Older hardware tends to favour the sprite commands whereas newer hardware favours polyvectors.

Lee

[Kitty Hello]

That's by design. ROTO and ZOOM were designed to draw the same as DRAWSPRITE if factors are 1.0 and rotation =0.
Stretch was added, because stretching a sprite with ZOOMSPRITE is really difficult.

[spacefractal]

its a old issue. But howover, if hotspot was on the top/left, im would newer have fighted like those isues im have.

Property its should have been as new command eventuelly, etc SETHANDLE x,y.

[Schranz0r]

SETHANDLE...

Doesn't work in GLB there is no "entitysystem" / Spritehandling in GLB.
You draw allways from the topleft corner, or you calculate it yourself.

[spacefractal]

It's still pity annoying in glbasic compared to blitzmax and monkey x. In glbasic there is many strange calculating and still cause me issues even today. The rotation commands is very annoying too, due strange hotspot and hard to calculate compared to other languages.

A SETHANDLE could have fixed it easier codning and more people could avoid virtual images.

So it's a old issue, but still exists.

[Kitty Hello]

Search the forum for pivot sprite. I did that ages ago

Gesendet von meinem GT-N7100 mit Tapatalk

[spacefractal]

im known and also used for PaintImage() function im created too. But.... There is still issues and even have seen some precision issues too.

There is a issue in ZOOMSPRITE, ROTOZOOMSPRITE and ZOOMSPRITEANIM commands. Those is glbasic most annoying commands to work with and is very fuzzy to and dosent like that way they works at all. Due limits on those commands, im could not uses rotations in Karma Miwa for one of the enemies too (the Ghost), due still HOTSPOT issue (when Retina is used).

This needs to been redesigned with beginner in mind, because the current hotspot handle is so very bad as its are. So that why im a a SETZOOMHANDLE x,y (with of course hotspot placement standard is center for combatible). So if  glbasic should handle the hotspot automatic, then its would been much easier to uses those commands with much less frustation.

When glbasic have a better hotspot handler with SETZOOMHANDLE x,y, im is pretty sure most of the fixed resolution games would not required a virtual image at all, but could scaling on the fly (and gain many fps on that). Scaling on the fly is NOT a issue with either example Monkey X or BlitzMax.

PS. STRETCHANIM does works excellent. No issues there.