On Tue, Sep 22, 2015 at 5:06 AM, Netanel M. <[email protected]>
wrote:
> Hi Claudio,
> I didn't realize that I found a bug, but when I tried the same code with a
> cocos map instead of a tmx map the issue didn't persist, I realized
> something fishy was going on..
> I apologize that the code was so unclean, I re purposed the code from that
> pymunk demo I talked about.
>
Don't worry too much, as far as bugdemos go it was 7/10.
>
> I took a look at the demo you made, and I noticed these comments:
>
> # WARN: this was hacked for bugdemo purposes only; don't use in real code:
> # lots of globals
> # position delta must use dt, else unpredictable view velocity
>
> I replaced all the 'from x import y' with one specific 'import cocos'. is
> this what you meant about lots of globals?
>
No, no problems with imports in any way. The 'update' function uses the
globals layer, collider, scroller; I assumed it was not from your real
code but a fast writing for the bugdemo.
> I suppose that's a newbie mistake, I thought it would make the code more
> readable.
> Now, what you said about multiplying the position by delta time. Do you
> mean something like this:
>
> def update(self, dt):
> last = self.get_rect()
> new = last.copy()
> new.x += self.dx * dt
> new.y += self.dy * dt
> self.collider.collide_map(tilemap, last, new, self.dy, self.dx)
> self.position = new.center
> scroller.set_focus(*new.center)
>
>
Yes,
> If I use this, I get pretty much the same result as when I don't multiply
> by delta time.
>
Yes, is a separate issue with the bug you reported
> You wrote it would create " unpredictable view velocity ", does that mean
> objects will be moving at different speed / at a different position than
> what they would appear to be going at?
>
When scheduling a function with schedule, , you ask pyglet to call at each
time it want to draw the window.
If the fps were not capped at window creation, you get different fps in
each machine you run. Visually, the action will run slower or faster.
If the fps were capped (the default), theres still the fact that pyglet
will try to honor the implicit dt (1/fps) but it will not be perfect, ie
will call with a bit less or a bit more that the theoretical time 1/fps. So
explicitly using the de will produce a more smooth movement
>
> p.s, thank you for the quick fix for the bug and the vigilance noticing it.
>
To clarify some things:
I put the WARN comment because
code in the public tends to be copied
I wanted to keep the ball rolling, and no time to tidy-up the code
(that payed-on, theres a suggestion and a separate PR from Dan Gillet)
I didn't know if the not so god parts were an artifact in the real_code
-> bugdemo transformation or defects in the real code, so mentioned just in
case
What helped to quick response is that there was a working bugdemo from the
start, so, thanks for that
--
>
> On Monday, September 21, 2015 at 12:32:06 AM UTC+3, Claudio Canepa wrote:
>>
>> I filled an issue in the bugtracker,
>> https://github.com/los-cocos/cocos/issues/248
>>
>> Theres a bug in RectMapCollider
>>
>> A partial workaround was committed to master. It probably lets you
>> progress in your game, but still show some defects:
>>
>> still seen two stuck cases
>> player pushes a wall on the left at the same time it wants to go down
>> player pushes a wall on the top side and wants to go left
>>
>> It only stuck at grid crossings
>>
>> The stuck in non definitive: releasing the pressure against the wall
>> resumes normal
>>
>> If not actively pushing against the wall the movement is normal
>>
>> Ask if you need help to use cocos from master.
>>
>> To @all
>>
>> I checked in Netanel bugdemo code with some modifications at
>> https://github.com/los-cocos/etc_code
>> If someone want to investigate and provide a real fix I will happily
>> merge.
>>
>>
>>
>>
>>
>> On Sat, Sep 19, 2015 at 12:32 PM, Netanel M. <[email protected]>
>> wrote:
>>
>>> I fixed it the issue where the sprite was flying off by using this code
>>> instead:
>>> layer.sprite.position = new.center
>>> instead of layer.sprite.position = new.position;
>>>
>>> But now, the sprite get's stuck whenever it hits the floor!
>>> I attached the fixed source. What could possibly cause this?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "cocos2d discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To post to this group, send email to [email protected].
>>> Visit this group at http://groups.google.com/group/cocos-discuss.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "cocos2d discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/cocos-discuss.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/cocos-discuss.
For more options, visit https://groups.google.com/d/optout.
