Serdar,
I thought about your memoization recommendation for a bit, and decided to
give it a try with a simple custom memoize decorator. I added a simple
modulus 360 to the rotation.setter, and moved the radian/sin/cos
calculations out into a separate (memoized) function. This netted pretty
good speedups:
Benchmark results:
Rotate Sprite only: 6.872406136000791
Move Sprite only: 4.335012871000799
Move Rotated Sprite: 6.798295626998879
These are pretty nice results, considering any rotated sprites still do
twice as many vertex calculations per frame compared to non-rotated
sprites. The memoize decorator is able to skip all of the calls to the math
module. Looks promising.
The only downside to this, is that as you can see from the code snipped
below, the memoize function has not size limit. If you only ever increment
Sprite.rotation by += or -= 1, then no big deal as the dict will only reach
360 keys. However, incrementing the Sprite.rotation by a decimal could lead
to a fairly large cache. I'm not sure just how large this could get, but I
wouldn't want it to start using up tons of memory. I'll have to do a quick
calculation to see how big we're talking here. Maybe an alternative would
be to limit the Sprite.rotation value to 2 or 3 decimal places, which would
be high enough precision for rotation while still keeping the memoization
cache down to the thousands instead of millions of members.
def _memoize(f):
class Memo(dict):
def __missing__(self, key):
ret = self[key] = f(key)
return ret
return Memo().__getitem__
@_memoize
def _calculate_angle(rotation):
r = -math.radians(rotation)
cr = math.cos(r)
sr = math.sin(r)
return cr, sr
On Thursday, April 7, 2016 at 2:05:14 PM UTC+9, Benjamin Moran wrote:
>
> I understand what you mean about pull requests directly to the default
> branch, but the 1.2.x branch is nicely separated with each released tagged.
> It seems to be fairly well organized this way.
>
>
>
>
> On Saturday, April 2, 2016 at 10:12:28 PM UTC+9, Daniel Gillet wrote:
>>
>> Hi Benjamin,
>>
>> Thanks for your help. I did also some researches on my side. It's good to
>> know that pyglet is expecting named branches. I think I'll manage to do
>> that. I'm just a bit surprised that I should propose that pull request onto
>> the default branch. The reason being that I can see some work that is meant
>> to be part of a 1.3 release. But my pull request is not really meant to be
>> for that release. Or maybe it has to. Anyway, I'll just make a named branch
>> from the pyglet tip and see how it goes. :)
>>
>> Daniel.
>>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
