Hi Jim.
> > 2. I changed how the alpha map is managed in PiscesTileGenerator to
> > something that's a bit clearer and uses less memory (the latter comes
> > from changing the +300 in the alpha tile allocation to +1. If there was
> > a good reason for using 300, please tell me).
>
> Did I do that? Wow. I wish I knew. There were probably some bugs in
> the alpha accumulation at some point. Since it was indexed by a byte, I
> find it hard to believe that it would need 300 entries of padding.
I don't know who did it. I didn't mean to imply I thought it was you.
In hindsight, the wording of "If there was a good reason for using 300,
please tell me" was pretty terrible. I only asked because 300 seemed like a
very out of place number and I thought it was a bugfix, but I couldn't see
for what bug, so I thought you might know since you've helped me out in
this sort of situation before (i.e. sx0, sy0 in Dasher).
> One thing - will we ever need more than one alpha map in practice? I
> don't believe we will since it depends on the maxalpha from the Renderer
> which is a fixed value. So, the hashmap cache is probably overkill
> compared to just seeing if the existing one is the right size, no?
Right now, it's true that there will never be more than one alpha map, so
you might say the HashMap is overkill, but I don't think this is a problem
because performance wise it costs nearly nothing and I think the code is easier
to read now.
But it's not a big deal, I can change it back if you want.
Regards,
Denis.
----- "Jim Graham" <james.gra...@oracle.com> wrote:
> Hi Denis,
>
> On 10/8/2010 8:53 AM, Denis Lila wrote:
>
> ...jim
