Hi,
- Kurosu a écrit :
> Might be interesting to check how much time each idea actually takes: it
> might not be the 1ms it checks.
> It also seems that process is not running in its own thread (so that it does
> not freeze the display), but rather serially:
> MainLoop -> InputRefresh -> AI
- Florian Köberle a écrit :
> Sure it would be cool to have the AI running in it's own thread(s). The
> difficulty is to ensure that the data does not get inconsistent. For
> example that a object gets removed from the object list because it has
> fallen into the water while the AI loops over
Hello
> That's why having a thread could be useful: even if it takes time, as long as
> the display isn't frozen meanwhile, it would be ok.
>
> Anyway, that needs some validation, at least on my target.
>
Sure it would be cool to have the AI running in it's own thread(s). The
difficulty is to e
Hi,
- Florian Köberle a écrit :
> The worse thing is that the character code uses even the width of
> sprites. Just have a look at line 533 in
> src/character/body.cpp:
> body_mvt.pos.x = GetSize().x / 2.0 -
> skel_lst.front()->member->GetSprite().GetWidth() / 2.0;
>
> The width depends on t
Hello
>> Secondly, it's not so easy to say that this part of the code is not
>> important for network. In the past, with iFlo, we noticed that
>> synchronization in the code that displays character members is highly
>> important. A very small difference in the member position means a
>> different t
Hi,
First, I want to say : Good work Christophe!
See other comments inline ;)
> just to sum up what has happened with my changes during the past weeks:
> - reduce memory usage due to unnecessary copies
> - do progressive loading of map ground image (avoid a 8-30MB duplicate image
> sitting in m
