Change origin at runtime

Post your work in progress addons and get feedback

Post » Sat Dec 05, 2015 10:27 pm

Well, you can strike my last comment. When an angle is changed, contruct 2 calls bbox changed after updating the angle. hmmm
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Sun Dec 06, 2015 8:57 am

@ruskul your thoughts are very useful to me and thanks for taking the time to respond!
I tried to change the angle to self.angle right after changing the origin, but construct is smart enough to NOT trigger an update to the collision box! It does exactly as you said, no unnecessary calculations without a reason because the engine understands there wasn't a real change in angle.

I also took a look at commonace.js but I couldn't find how the collision poly is moved after rotate/scale. All those actions just call this.set_bbox_changed();
B
13
S
5
G
1
Posts: 116
Reputation: 1,805

Post » Sun Dec 06, 2015 10:50 pm

Ya you are right, I realized when looking at the change angle that it only changes the angle if it is different. You might try getting Ashley to weigh in on the conversation. There have been a few times when I wanted to do something but didn't know if I was overlooking something or if it was part of the blackbox portion of c2 we can't touch.

Either way, he might add it to an update if it is something simple. One workaround you might try is simply to add an offset vector and store it to the sprite. you could then use that offset to artificially change its position for visual appearance or use it in collision detection as overlapping offset. I know it doesn't actually address the problem though.... Personally I hate workarounds even if they did work perfectly, lol but here I am offering a "why don't you do this instead" type comment...

It is a bit of a conundrum.
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,153

Post » Mon Dec 07, 2015 3:29 am

Thanks again for your help man! Although I know he's extremely busy I will tag @Ashley and maybe he can shed some light when he has time!
BTW in common_prelude I see tons of stuff about points cache and I'm thinking It might have to do something with updating the poly.
B
13
S
5
G
1
Posts: 116
Reputation: 1,805

Post » Mon Dec 07, 2015 5:36 am

It looks like you'll need to call this function:
Code: Select all
CollisionPoly_.prototype.cache_poly = function(w, h, a)

The only catch is it won't update if the width, height or angle haven't changed. So you'll probably need to change one of those first.

I only took a quick look so I didn't investigate where that function is usually called. You may even be able to change the size or angle of the object to force a update without calling the function if it's called every tick anyways. Or instead you could change the .cache_width value from the polygon.
B
92
S
32
G
106
Posts: 5,272
Reputation: 69,455

Post » Mon Dec 07, 2015 11:58 am

I can't guarantee that changing the origin at runtime is actually ever going to work. The entire engine has been designed with the assumption that origins do not change. In particular you may end up getting strange results with the collision cells optimisation and render cells. There is a lot of non-obvious engine code that depends on this stuff as you appear to be finding. So why do you need this anyway? Can't you work around it with events?
Scirra Founder
B
395
S
231
G
88
Posts: 24,367
Reputation: 193,694

Post » Mon Dec 07, 2015 2:07 pm

@R0J0hound you're right. It won't update unless a rotation or scaling is performed, so I will use your solution as a workaround!

@Ashley thank you very much for taking the time to reply! I perfectly understand that changing the origin at runtime can break many things. The thing is that I'm doing an application, not a game, and I only really need the collision box to register mouse clicks and for the drag & drop behaviour. It's a simplistic keyframe animation app in which changing the origin is a needed feature. I currently handle this with invisible sprites to perform rotations and do linear interpolations between keyframes.
But I have just added a feature to assign parent-child relationships to sprites (to make it easier to animate) and i get very strange values in the interpolated frames. I suspect that is because of the "fake" origin points I'm using and that's why I'm seeking a way to implement "proper" origin points.
B
13
S
5
G
1
Posts: 116
Reputation: 1,805

Previous

Return to Work in Progress Addons

Who is online

Users browsing this forum: No registered users and 0 guests