SetScale broken!

Nevermind. False alarm!

Maybe?

The main problem stemmed from the fact that images are rotated after they are scaled.

I removed the rotation of the ship to try to debug the problem, and when i did it was clear I wouldn't be able to tell if I'd flipped the image horizontally or not. Then it occured to me that perhaps it was flipping the image, and when I saw it apparently flip on both axes, it was really just flipping on the Y and the rotation afterwards caused it to appear to be a flip on both axes.

Well that was the case. Flipping an image by setting a negative scale does work.


The only remaining issue was one I had wondered about when examining the internal code. If you flip the image, what happens to the handle?

Well it turns out if you flip the image, then a handle that was in one corner now behaves like it is in another corner. So if you flip left to right, your 0,0 handle now causes the image to blit as if the handle is at the top right corner instead.

This does not seem to cause any issues with collision testing, and it even works with text.

But I have to wonder if the handle changing position like that is a good thing or intended. I guess I will just code around it in my sprite system. It's not that difficult.

So can I assume then, since this was moved, that the image drawing at the wrong location when flipped is NOT a bug, and is intended behavior?

Sorry, I read the first sentence and decided you had worked out there was no bug.

The SetImageHandle docs state:


The docs for SetRotation and SetScale are a little more ambiguous as they do not specify the order in which they are performed. Actually that description above is ambiguous also as the handle is subtracted from the draw operation's source coordinates (0,0,width(),height()) NOT the x,y destination coordinate of the DrawImage command.

The fact that no matter what rotation or scale I throw at an image that has it's handle in the center of the image still causes the image to rotate around it's center leads me to believe there is no problem and what you are experiencing is intended behavior.

Ambiguity is bad when you're documenting a subject.

Shouldn't ambiguous, incorrect or missing doc entries be considered bugs?

I'm not so concerned about the docs here. I just am not sure that setting a negative scale for an image should result in it drawing at a different location.

Try this test progam:

Strict

Local rot,x,y

Graphics 640,480

'AutoMidHandle True	'image will rotate around it's center

Local image:TImage=LoadImage("bullet.png")

Local scale# = 5
Local sizechange# = 0.1


While Not KeyHit(KEY_ESCAPE)
	Cls
	ResetCollisions

' draw the first image at 5 times the size and on an arbitrary angle
	
	SetScale 5,5
	'SetRotation 125

	DrawImage image,320,240

' add the first image to the first collision layer at same postion, rotation 
' and scale as it has just been drawn

	CollideImage image,200,200,0,0,1

' move the other image relative to the mouse and rotate it continuously

	x=MouseX()
	y=MouseY()-20
	rot:+1
	
	scale# = scale# + sizechange#
	If scale# < -5 Then sizechange# = -sizechange#
	If scale# > 5 Then sizechange# = -sizechange#
	
	SetScale scale#, 5
	SetRotation rot
	DrawImage image,320,240

' test the image at it's current rotation, scale and position with images
' that have been added to the first collision layer

	If CollideImage(image,x,y,0,1,0)

' reset scale and rotation states so our text is drawn correctly		

		SetScale 1,1
		SetRotation 0
		DrawText "COLLISION!",20,20

	EndIf

	Flip
Wend

If AutoMidHandle is True all is well, but if not, then things go funny for the second ship.


Oh while I'm at it too... That's the collision example. Why is it when I click to open an example, the IDE opens the actual example file, so when I makde changes to try things out, I end up modifying the ORIGINAL? That seems like horrible behavior, eventually I'm gonna screw up all the examples trying stuff out cause I can't even choose not to save when I do a build. And who knows where all those exe files and subdirectories with compiled files are going because the IDE leaves those around too.

When I click on an example it prepends a dot to the file name.

My bad. I could have sworn I closed it and reopened it from the help file and it was still the way I'd left it, but I guess not.

I just tested it and it is leaving crap around when I compile, but it isn't screwing up the original examples. So one less strike on the IDE. :-)