world looses its consistency

[GoogleCodeExporter]

What steps will reproduce the problem?
1.create a world with some objects
2.access the objects list and move all objects do the right/left with a number 
of pixels
3. try syncing the world with each object to make sure
4. notice now tat the collisions are not accurate at all

Original issue reported on code.google.com by RavenX86...@gmail.com on 1 Feb 2011 at 9:28

[GoogleCodeExporter]

Have you also called PhysObj::update() for each moved object too?

Original comment by lucadelt...@googlemail.com on 1 Feb 2011 at 10:11

[GoogleCodeExporter]

yeap... first tried with update... and after with both update and sync

solved it by (remove object.. change pos .... add object) but it's not a normal 
solution....

Original comment by RavenX86...@gmail.com on 1 Feb 2011 at 11:06

[GoogleCodeExporter]

I'll take a look at this this evening see if I can reproduce and find the bug.

Original comment by lucadelt...@googlemail.com on 1 Feb 2011 at 11:32

[GoogleCodeExporter]

I can confirm incorrect behaviour in UniformSleepSpace (BruteSpace and 
UniformSpace behave as would be expected) I'll take a quick look to see if I 
can find the cause now, though i'm quite tired so it may have to wait till 
tomorrow.

Original comment by lucadelt...@googlemail.com on 1 Feb 2011 at 11:05

• Changed state: Accepted

[GoogleCodeExporter]

well ... for me it actually happens for UniformSpace when placing a circle 
falling on a concave generated with Tools ... but try fixing the USleepSpace 
and lets hope it solves it :)
Thx again for looking into it

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 7:59

[GoogleCodeExporter]

Oh.. okay then. Do you think you could send me some code that will reproduce 
the problem then?

Original comment by lucadelt...@googlemail.com on 2 Feb 2011 at 8:57

[GoogleCodeExporter]

here... made a Main for the bug

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 9:26

Attachments:

• Main.hx

[GoogleCodeExporter]

Ahah okay, I can't test right now but I can see one error with your code. You 
are not allowed to move static objects. Static objects have various 
optimisations made for them with the assumption that once it's added to the 
space, it will remain in that exact position and shape.

If you want to have a kinematic object (static but moveable by yourself) then 
create a normal dynamic object, add it to the space and then afterwards call 
physobj::stopAll(). This is also necessary should you want a static object that 
still has a velocity (for things like conveyor belts and trampolines).

Original comment by lucadelt...@googlemail.com on 2 Feb 2011 at 10:08

[GoogleCodeExporter]

Oh.. yeah sry.. forgot I read about that... but one more question... In my 
situation (making a platformer game)  I need to move everything except the 
player... so I was wondering if there is anyway to directly correlate the 
viewport with the rendered image.. without the need to move the whole world .

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 10:16

[GoogleCodeExporter]

It would probably be a lot better if instead, you kept the world still and 
moved the player instead, transforming the graphical output instead to make it 
look like player remains still on the screen which I guess is your intention.

the viewport is strictly rectangular so the easiest way to fit it to your 
rotated screen viewport would be, assuming player is at position px,py in the 
centre of the screen of dimensions w,h with rotation (radians) t.

dx = w/2 abs(cos(t)) + h/2 abs(sin(t))
dy = w/2 abs(sin(t)) + h/2 abs(cos(t))

viewport.minx = px - dx
viewport.miny = py - dy
viewport.maxx = px + dx
viewport.maxy = py + dy

(This is totally unchecked but I believe it to be correct) If i'm correct 
there, the viewport will always be the smallest viewport that still fits your 
rotated screen (So the best that can be done using this feature)

Original comment by lucadelt...@googlemail.com on 2 Feb 2011 at 10:28

[GoogleCodeExporter]

That assumes you actually need to rotate the world relative to the player's 
point of view, otherwise the viewport is simply:

viewport.minx = px - w/2, viewport.maxx = px + w/2
viewport.miny = py - h/2, viewport.maxy = py + h/2

and it will always be exactly the right size/shape to fit the screen :P

Original comment by lucadelt...@googlemail.com on 2 Feb 2011 at 10:29

[GoogleCodeExporter]

yeah .. thx for the reply .. that's something I already tried .. and i'm trying 
to implement it again. What I was wondering was if there is a way(or at least 
should be implemented .. it's not so hard to move the graphics only) .. to 
access Body.graphic in a way relative to the viewport and not to the world

sry for all this offTopic posts... but couldn't find a forum :)

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 11:13

[GoogleCodeExporter]

wait.. sry forgot i had a movieclip container specially designed for situation 
where i have to move the graphics... :) sry for noob question above.

solved by container.x = -viewport.minx; container.y = -viewport.miny;

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 11:46

[GoogleCodeExporter]

also as a suggestion... maybe there is but i couldn't find.. there should be a 
way [readonly] to check the size of the Space after creation.

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 12:11

[GoogleCodeExporter]

my bad above as well.. i was searching for width in Space...

Original comment by RavenX86...@gmail.com on 2 Feb 2011 at 12:17