On Mon, Jul 30, 2012 at 5:01 PM, Nitneroc <[email protected]> wrote:
> I'm sorry for this pretty vague question, but i'm a bit helpless here...
>
> When my game starts, it creates various layers, scrolling_managers, it
> generates a random landscape and about a thousand sprites and loads a large
> background. I understand this can take time.
>
> But what's troubling me is that the update() function of my character
> (which is scheduled), receives this elapsed time parameter :
> 1st time : 0
> 2nd time : 0.059187720199 which isn't that a big problem
> 3d time : 1.53404387161 which is really long
> 4th time : 0.00426641644389
> and then it's always something like 0.00177292282634
>
>
> The real problem with this 1.5sec is that much should happen during this
> time, and no collision is tested and the character teleports to strange
> places
>
Understandable.
> I thought that scheduling the character's update function in on_enter()
> could solve the problem but it does not.
> The character is created after the layers, background, landscape and every
> other sprite.
>
>
If really happens only on startup, an easy but not robust way can be to
schedule the update of problematic actors only after a small amount of time
after the on_onter.
You can use an action Delay(e) + CallFunc(schedule_the_update) to this end.
Profiling the code proved it was pyglet's clock.py unschedule function that
> took 1.52sec running, but I don't really know what this means...
>
>
Suspicious, but needs investigation about why so much.
> I guess you won't be able to help much without my code, but maybe some of
> you know this problem... Is it something I have to deal with ? Do you think
> I should create everything that rely on steady fps after some time has
> passed ?
>
> Thank you very much for reading.
>
A common workaround to deal with infrequent big dt's is to intercept the
clock and :
if dt > dt_thershold:
dt = dt_safe
where dt_safe depends on the app.
For consistency is better if the general app clock can be cheated; for
pyglet in the general case that is not so straightforward.
But in some situations it suffices to do this dt cropping in the individual
update(self, dt) for a handful of problematic entities.
Do you think it can work in your use case ?
--
You received this message because you are subscribed to the Google Groups
"cocos2d discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/cocos-discuss?hl=en.
