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 trajectory for the weapon projectile.
>
> I thought to leave physics (including rectangle collision) using
> Double. But indeed, it does not seem sufficient. There are for
> instance uses of the Sprite scale_x/scale_y for some physics.
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 the rotation and zoom and thus on what RotoZoom
calculates. The current situation isn't ideal as different versions of
the called library functions (rotozoomSurfaceXY and rotozoomSurface)
might calculate different results, but doing more calculation in non
fixedpoint arithmetic might make things even worse.
By the way you can get probably a very large performance boost by
rewriting the character code. It calculates a lot of stuff multiple
times where it isn't necessary.
Take for example line 283 in character/member.cpp:
Double pos_x = radius * (cos(angle_init + angle_rad +
mvt.GetAngle()) - cos(angle_init + angle_rad));
to make it more obvious what happens here let me write it this way:
Double old_angle = angle_init + angle_rad;
Double new_angle = angle_init + angle_rad + mvt.GetAngle();
Double wrongly_added = cos(old_angle);
Double should_be_added = cos(new_angle);
Double to_add = should_be_added - wrongly_added;
Double pos_x = to_add;
As you can see the code "undos" a previous calculation by doing the same
calculation again. Also if we weren't using that cheap fixedpoint cos
and sin function it would be quite expensive to call cos that often.
Another big performance problem with the character code is that for
example the relation between the attached members and the skeleton isn't
stored with pointers. Instead Member::ApplyMovement loops over all
attached members and skeleton combinations and find pairs with string
compares.
This list of shortcomings of the character code is far form being
complete. If you want to rewrite it and need more information let me know.
>
>> *From my point of view*, we want network on ARM, it may be the future of
>> Wormux.
>
> The Maemo port also expects to use network game. The first problem was
> memory and it's gone. Now, IA is a bit laggy as I said on such
> platform. It might be due to too exhaustive search, or basic algorithm
> implementation (I think I saw the straight line shoot be (length/step)
> * num_objects in complexity, while it should really be num_objects).
Generally the AI should not be laggy. As the thinking is split in a lot
of small packets (called ideas) which can be separately checked. You
could try if setting REAL_THINK_TIME_PER_REFRESH_IN_MS to 0 helps. If it
doesn't then the probably to much calculation happen within one idea.
About the straigth line shot: How do you want to know if you hit the
ground without checking every pixel in the way of the missile? But
generally it's true that there is a huge room of improvements for the AI.
>
> > That means that if the Double class causes too much performance
> > problems, we should remove it.
>
> I think it is greatly handicapped by:
> - the bump from 32 to 64 bits internal storage: gcc sucks at
> non-native integer size maths
> - the increased requirements in some computations: number of
> iterations for sqrt16 has increased from 6 to 20 (I would have though
> 12 to be sufficient)
I had some unchecked test case classes but I lost them due a recent hard
disk failure. If I remember the large number of iterations where
necessary when calculating the square root of large numbers. Anyway my
64 bit version of the sqrt function isn't that much optimized like the
one which was there for 32 bit.
>
> As I said, ideally, we would move from the current 48.16 fp precision
> to (16+x).(16-x) (4<x<8) precision. It may not be feasible (have to
> recompute and update all specialized functions).
I could imagine that angles need the 16 bit of precision as they range
only from 0 to 2 pi. What you could try is to add (conditional) code
which checks if a calculation with Double resulted in a larger value
then you can store with a 32 bit version of Double. If that check fails
you abort or print something to the command line. This way you could
find all the places where we actually need 48.16 and eliminate them. If
nothing helps you can change those places to calculate in a different unit:
e.g. changing
Double distance_in_mm = 1000000;
to
Double distance_in_m = 1000;
Best regards,
Florian
_______________________________________________
Wormux-dev mailing list
Wormux-dev@gna.org
https://mail.gna.org/listinfo/wormux-dev
