----- Florian Köberle <flor...@fkoeberle.de> 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 the object list.
Indeed, and wind strength/direction could change too, meanwhile. I guess we
should have it do:
- start only if no physical object is moving (but isn't that supposed to happen
by the end of the turn?)
- force the random events to not occur once it has started (such as wind, or
weapon box, for which it could force drop)
That way, all that matters to the IA is constant while it thinks, and the
camera moves.
> I don't get your algorithm.
I think my time is better invested in implementing and testing than explaining
it further, then.
> However I had once the plan to make a class
> which has a two dimensional array of the size of the map (in pixels).
> The array stores what at each pixel of the map is.
>
> This array gets constructed at AI construction time. Then when it's the
> AI's turn the objects of the map are "drawn" in that array. e.g. if an
> object is at coordinate (20, 30) with the size of 2x1 then the array
> elements a[20][30] and a[21][30] hold a reference to that object.
>
> This array can then used to find out which object is at a specific pixel
> position in constant runtime.
>
> At the next turn the AI reuses that array. It's not necessary to clear
> the whole array but only the places where objects have been. For that
> purpose a list holds a list of the rectangles which have been drawn into
> the array.
I think the array could also be "quantized", ie defined for a set of, say,
16x16 pixels. After all, most object collision rectangles are of that order of
size. Any object could occupy a 2x2 block of them. For the ground, the number
of non-transparent pixel would defined whether it is filled or not.
That may sound coarse, but in a sense, that would mimic the approximation a
human player also performs: sometimes we miss by so little an opponent but
still get it through the blast, sometimes we hit the ground before that, and so
on.
Anyway, that's not something I will try immediately: too much side effort.
> Is a 32 bit fixedpoint class really slower then float on the platform
> you optimize for? I have heard that good fixedpoint arithmetic can even
> be faster then floatingpoint arithmetic.
It completely depends on the hardware (FPU efficiency? cache size?), and you
have heard it for x86. I unfortunately can't test it well, but for an example,
see attached code, and its output on a core2 system:
Double sqrt=21081691.985 70176082 cycles
float sqrt=21081692.746 2222050 cycles
Double cos=65392.478 1986393 cycles
float cos=63578.348 12535582 cycles
Double sqrt is around 30 times slower, cos is 6 times faster. There was of
course a reason for sqrt16 showing so high.
Anyway, as I said, (Double) -> float suppressed the problem, so...
> You could set a breakpoint on the "print to large value warning"-statement.
True indeed.
Christophe
_______________________________________________
Wormux-dev mailing list
Wormux-dev@gna.org
https://mail.gna.org/listinfo/wormux-dev
