Hi Denis,
On 10/12/2010 6:01 AM, Denis Lila wrote:
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).
It was most likely me since this code hasn't been touched much since I
hacked it together. I wasn't put out by your comment, I was simply
making a public showing of confusion to cover my embarrassment. ;-)
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.
No, I think it's OK if it doesn't show up on any benchmarks...
...jim
