>> Yes, but the distance to the nearest resource of two fields in listedAddr
>> can at maximum differ by 1.
>
> Sorry, I don't get what you mean here ?
Ignore this comment. I mixed things up. I don't know the AI code.
> Do you have another suggestion for the fall back ?
For now we are fine. But if we choose to optimize the size, we
should use something like:
After: (line 2280)
while (listCountRead < listCountWrite)
{
Put:
// Check if listedAddr could have an overflow
// The current field can spawn 8 fields at maximum
if(listCountWrite+8>=listCountRead+size)
{
size_t oldsize=size;
FILE *MapLog = globalContainer->logFileManager->getFile\
("Map");
fprintf(MapLog, "changed size to %d, Resource Type: %d\\
n", size, ressourceType);
size>>1;
Tint *listedAddr2 = new Tint[size];
for(int i=0; i<=oldsize; i++)
*listedAddr2[i]=listedAddr[(i+listCountRead)&ol\
dsize];
delete listedAddr;
updateGlobalGradientVersionSimple<Tint>(gradient, liste\
dAddr2, listCountWrite-listCountRead, gradientType);
size<<1;
return;
}
If we make size high enough that the overflow will almost never happen,
the overhead will not worsen the runtime much.
But this handling is not beautiful.
> Which space you want to save?
> I see two things:
> -1- Computing the listedAddr[] of forbidden gradients differently.
> Yes, that's a good idea. Go ahead and test it!
> -2- Reducing the size when we can guess it will not overflow.
> I'm not sure I want this, but if it shows exceptional speedup I'll take it
> into
> account. Go ahead and test it! (again)
I mean both. And I will test both - sometime.
>>>Sounds ok to you ?
> Anyway the worst exploit ever will be the AI to make bad choices at
> long ranges.
I have closed the bug today.
--
Kai Antweiler
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
