so if you have the phone rotated 90 degrees, the top-left corner is (0, 0)
thanks [import]uid: 4044 topic_id: 258 reply_id: 300258[/import]
As far as I can tell, you have explicitly to convert coordinates to and from the physical display space (i.e. 0,0 at top-left corner when device is in portrait mode) and your apps “virtual” display space (i.e. 0,0 at a corner of your choosing).
It would be nice if you could rotate the display to a chosen orientation and have Coronas’ display object automatically use the top-left corner of that orientation as the origin, but alas, that seems not to be possible atm.
[import]uid: 1581 topic_id: 258 reply_id: 324[/import]
thanks - just doing the transformations myself then [import]uid: 4044 topic_id: 258 reply_id: 325[/import]
You could always define a variable. local landscapeX,landscapeY = 0,480 or something like that and just always call that variable as your x,y origin, or something along those line.
I’ll add this as a feature request to our bug tracker as it would indeed be nice to have. [import]uid: 5 topic_id: 258 reply_id: 329[/import]
I think the best approach at this point is to create a display group, rotate it 90 degrees, and then position that group so its (0,0) point is at the top left of the display. Then, anything added to the group can inherit that coordinate system with the desired origin.
(I agree that we should support this more intuitively, though.) [import]uid: 3007 topic_id: 258 reply_id: 333[/import]
thanks evank, worked like a charm [import]uid: 4044 topic_id: 258 reply_id: 346[/import]
Evan, The problem with this solution is it is not consistent enough throughout the interface with pesky little bugs popping up here are there. One problem: touch events are delivered with the non-rotated coordinates. Another problem I am having is that occasionally, but consistently object are not moving based on the rotated coordinates. I have one routine that about 80% of time moves objects as intended, but the other 20% of the time they go off in strange directions. Everything snaps into place, though, once a touch event occurs. [import]uid: 4639 topic_id: 258 reply_id: 1327[/import]
im having problems with this as well, see http://developer.anscamobile.com/forum/2010/03/23/animation-bug-0.
To me it seems that the coordinates are local to the group through transitions and when rotated to certain angles but when they hit 90, 180 things revert back to the display coordinates. Ive tried lots of different approaches but cant find a solution that works 100% of the time.
What I was doing was rotating a mastergroup through 90, 180 etc… for the different orientations of the phone for landscape and portrait gaming. hoping the internal groups would retain their local coordinates. [import]uid: 5354 topic_id: 258 reply_id: 1328[/import]
I’ve just pinpointed the bug that was causing my (immediate) problem.
I had several images in a common group. The group as a whole was rotated 90 degrees to force a landscape orientation. As images are removed from the set I adjust their layout and then use transition.to for a smooth flow into the new layout. Most of the time it would work correctly, but occasionally (and very consistently at certain points) the images would fly off in strange directions. I’m assuming they would go to the non-rotated coordinates (swapping x for y), but I’m not sure. All the math & seemed correct and all the logging values came out correct. And for some strange reason, on the next touch event (and without recalling the layout subroutine), all of the images would snap into their correct places. I was having a hard time figuring out the common factor for when it would not transition correctly when I finally noticed that those times the scale factor did not change from the previous layout.
Specifically, when using transition.to, if I included xScale = scaleAmnt and yScale = scaleAmnt AND scaleAmnt was equal to the current values for xScale and yScale, then I would get the strange positioning behavior. Leaving xScale & yScale out of the parameter list ALSO produced the strange positioning behavior. My work around right now is to check for the new scale value being equal to the current value and if so, subtract 0.02 from the value and set a timer to recall the layout routine (which will reset the scaling to the correct value without the strange positioning behavior).
Hope this helps anyone having a similar problem.
- Stephen [import]uid: 4639 topic_id: 258 reply_id: 1330[/import]
Hi Stephen
I think this is a bug in 1.1 and is fixed in the beta (I clarified mine worked after when it didnt before). There is still an issue with the touch listener not following its target when rotated but that should also be fixed quite soon. [import]uid: 5354 topic_id: 258 reply_id: 1357[/import]
Hi Matthew, can you send us a sample demonstrating your touch listener issue to beta@anscamobile.com
thanks,
walter [import]uid: 26 topic_id: 258 reply_id: 1361[/import]
Nevermind, looks like Evan already talked to you [import]uid: 26 topic_id: 258 reply_id: 1362[/import]
Yup but here it is for anyone who is interested. You can click the box before to change its colour but after the transition its not clickable
– Hide Status Bar
display.setStatusBar(display.HiddenStatusBar)
– Interface
interfaceGroup = display.newGroup()
interfaceGroup.xReference = 160
interfaceGroup.yReference = 240
local rect1 = display.newRect( 110, 350, 100, 100 )
rect1:setFillColor(255,255,255)
– Touch Response
local function buttonAction()
rect1:setFillColor(math.random(0,255),math.random(0,255),math.random(0,255))
end
rect1:addEventListener( “touch”, buttonAction )
interfaceGroup:insert(rect1)
masterGroup = display.newGroup()
masterGroup.xReference = 160
masterGroup.yReference = 240
masterGroup:insert(interfaceGroup)
transition.to(masterGroup, { rotation=180, time=400, delay=2000 } )
[import]uid: 5354 topic_id: 258 reply_id: 1363[/import]
Hi Matt, good catch! We’ve identified the issue. Usually this doesn’t happen if you the touch listener is attached to a *direct* child of the group you’re rotating.
In your case, the child that’s supposed to receive the touch event is double nested. That is, the child is in a group (the parent) which is in another group (the grandparent). And you are trying to rotate the grandparent. Here, the bug is that things not updating under the hood so the hit-test on your child fails.
We’ll fix this in the next beta update.
In the mean time, you can try the following which *will* work. I’ve basically removed the masterGroup and rotate interfaceGroup instead; clicking on the rect will then change color:
– Hide Status Bar
display.setStatusBar(display.HiddenStatusBar)
– Interface
interfaceGroup = display.newGroup()
interfaceGroup.xReference = 160
interfaceGroup.yReference = 240
local rect1 = display.newRect( 110, 350, 100, 100 )
rect1:setFillColor(255,255,255)
– Touch Response
local function buttonAction()
rect1:setFillColor(math.random(0,255),math.random(0,255),math.random(0,255))
end
rect1:addEventListener( “touch”, buttonAction )
interfaceGroup:insert(rect1)
transition.to(interfaceGroup, { rotation=180, time=400, delay=2000 } ) [import]uid: 26 topic_id: 258 reply_id: 1364[/import]
Hi Walter
That would fix that example but I wrote that code as a simple demo of the bug to help you identify it rather than a direct copy of my code which is much more complicated. I have at least 8 outer groups to enable different rotations of the whole interface for different orientations. Inside all those groups are a bunch more groups which all have game elements inside, characters, interface, buttons, text boxes, menu items. So the buttons are nested quite deep down in the setup im using so the above code wouldn’t work.
Evan said he would get a build out once your Android beta is released so im waiting on that before I can continue development. [import]uid: 5354 topic_id: 258 reply_id: 1365[/import]
Yup, we’re working on a couple of bug fixes. This is something that’s burning red in our bug base. [import]uid: 26 topic_id: 258 reply_id: 1371[/import]
In regards to landscape mode and making the top left be 0, 0 co-oridnates… has this still not changed?
In regards to landscape mode and making the top left be 0, 0 co-oridnates… has this still not changed?