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 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.
A clean solution would be to make a copy of all relevant data just for the AI when the AI starts thinking. If that data is read only you can even run multiple threads using the same data. > >> 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? >> > My analysis has been rather rough in that I was only looking at whom made all > those GetObjectAt calls. > Still, for each position, the problem is not checking ground/vacuum, but > checking every object. > > Another way to do GetCollisionObject (very rough) would be: > - sort before thinking objects with their abscissa > - for abscissa to first object abscissa by step x: > . Ground/vacuum? > - for first object within reach to last object within reach > . Check current object (the Contains(pos) / IsDead() checks) > . for current object position to next object: > . Ground/vacuum? > > This way, each object/character should be tested only once, and not > distance/step times, while doing the same number of checks for the ground (or > little more, to be extra-careful with bounds of the above loops). Same > *might* be applied to any trajectory. > I don't get your algorithm. 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 believe the AI does not need to compute ratings with Double for instance: > it is so local and does not need to be very precise as far as I see. > > You are correct here. The AI calculations don't need to be done with Double. The big question is: 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. > I saw that indeed: I had it changed back to 32bits, saw that even the menus > got corrupt, checked the max value in the internal representation (was > upwards of 600000 alone for the menus, while 32bits only allows 2^16) and > dropped the idea until I figured where those values came from. If I reduce > the cases where Double is used, it might help tracking them. > You could set a breakpoint on the "print to large value warning"-statement. Best regards, Florian _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
