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
ROTOZOOMANIM have the same issue.
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:
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)
(http://dl.dropboxusercontent.com/u/3236515/chicken/hotspotissue.png)
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.
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
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.
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
Quote from: spacefractal on 2013-Dec-10
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
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):
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.
My PRM has a bit about hotspots for the different sprite commands - might be worth having a look.
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)
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
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.
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.
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.
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.
Search the forum for pivot sprite. I did that ages ago
Gesendet von meinem GT-N7100 mit Tapatalk
im known and also used for PaintImage() (http://www.glbasic.com/forum/index.php?topic=9848.0) 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.
Could all of this be fixed / replaced with a custom sprite system TYPE using POLYVECTORs?
Include various anchor point (hotspot) presets (TOP_LEFT, MIDDLE_CENTER, BOTTOM_RIGHT, etc), or custom based on percent (25%, 75%).
Have properties such as: x, y, rotation, zoom, colour (maybe even allow all four corners to have a unique colour. Colour should be optional for older devices that have trouble with this feature).
Then calculate everything inside a Draw() method, using SIN() and COS() for rotating the corner points. Should be fairly quick in execution.
Add texture map / sprite sheet functionality for improved speed by batching the actual display of each sprite till the end of the frame so sprites that share the same texture can be drawn at once, lowering draw calls.
Utilizing the anchor property, you can carry this over to a powerful GUI system, for resolution independent displays. For example, you can draw a sprite to any of the four corners easily if their anchors are set properly, and you don't have to calculate the size of the sprite and subtract from the screen edge, etc.
I must have most of this done scattered though various sections of my libraries. But it would take a bit to glue it together into a proper library TYPE. Be nice if such as system would be built in and included with GLBasic.
not all games needs POLYVECTORS nor all images, but far from all people is aware how they uses them. But POLYVECTOR is a quite advanced command, so its not for the beginner in mind, but its a very great command. no doubt. Im did uses that too for many uses (but not for all images).
But for the normally ZOOM and ROTATIONS commands, its just only frustations to uses them. That why im thinks SETHANDLEZOOM command could been a great idea. This would give the control back to the user, using the hotspot anchor point where they want. But this is just a request, no other than that.
Also recently its seen Erico have fighted with extractly this issue too when drawing the virtual image to the backbuffer, due this issue.
So im are not alone....
Being able to set an offset handle for all sprite commands would be useful.
I dont think i agree with the offset idea.
When it comes to raw GLB commands, i prefer the simplest commands.
When a command becomes too elaborate, theres more opportunity to create an error in a program.
I use zoomsprite for analzing images...the only blurring or fuzzy i see; is when the image is scaled to a size that is not a power of 2.
The offset im perfectly content with adjusting the x and y as needed with variables....more powerful this way imo.
Does this help?
http://www.glbasic.com/forum/index.php?topic=1457.msg9615#msg9615
the issue with the center genereal, is the placement can been still been unprecision due float. That would not been happens on a top/left border. Its still exists, but not something im will add to the bug list at all. This issue can been skipped.