Mac v6 beta test

[Skyld]

Originally Posted by cbk1994

The problem with a highlight is probably because GraalControl's y is not zero (the trial bar at the top moves it down). This has already been reported but apparently not fixed.

I would not consider this a problem. The GraalControl is movable, therefore it is unwise to assume that it's X and Y will be zero. It's not hard to use relative positioning, or even just saving the position of the control before moving it if you need to refer back to it.

You can position things independently of GraalControl by making them child objects of GUIContainer I think.

[cbk1994]

Originally Posted by Skyld

I would not consider this a problem. The GraalControl is movable, therefore it is unwise to assume that it's X and Y will be zero. It's not hard to use relative positioning, or even just saving the position of the control before moving it.

It's a problem because it's not documented and it didn't happen in v5. From what I understand about it, it's also a problem because he's drawing on the tile layer, therefore the coordinates should be relevant to tiles. The only way to fix it would be to add GraalControl.y / 16 to the y you're drawing at, which is nasty if GraalControl's y is not a multiple of 16.

EDIT: This may not be the bug I'm thinking of—it seems to be the same one Tig was having with his level editor, but I thought it was fixed.

[Skyld]

Originally Posted by cbk1994

It's a problem because it's not documented and it didn't happen in v5. From what I understand about it, it's also a problem because he's drawing on the tile layer, therefore the coordinates should be relevant to tiles. The only way to fix it would be to add GraalControl.y / 16 to the y you're drawing at, which is nasty if GraalControl's y is not a multiple of 16.

Probably better to use things like worldx() and worldy() for that, perhaps with GraalControl.globaltolocalcoord() if needed, so that you do not need to really worry about whether the GraalControl's position is a multiple of 16 or not.