Re: py-lepton (possible?) issue
Casey Duncan
suggested to setup.py, thanks again!
-Casey
On Sat, Feb 14, 2009 at 12:08 PM, Ken Lauer <sir...@gmail.com> wrote:
> Wow, thanks for the quick fix and reply. It's working much better with your
> suggestion.
> In my rush to throw explosions into my game, I took the lazy approach which
> ended
> up being more difficult in the end. At least it led to a bit of a bug fix,
> so it wasn't all
> in vain!
>
> By the way, to compile the SVN under Windows (working on mingw/vs2008), it
> was necessary
> to modify setup.py to include 'groupmodule.c' in lepton.renderer (for
> Vector_new):
>
> Extension('lepton.renderer',
> ['lepton/group.c', 'lepton/renderermodule.c',
> 'lepton/groupmodule.c'],
> include_dirs=include_dirs,
> library_dirs=library_dirs,
> libraries=libraries,
> extra_link_args=extra_link_args,
> extra_compile_args=compile_args,
> ),
>
> I'm looking forward to the next version. Keep up the great work.
>
> Thanks again,
>
> Ken
>
> On Sat, Feb 14, 2009 at 1:47 AM, Casey Duncan <casey....@gmail.com>
> wrote:
>>
>> On Fri, Feb 13, 2009 at 4:29 PM, Ken Lauer <sir...@gmail.com> wrote:
>> > Hello,
>> >
>> > First of all, thank you for all the work you have put into py-lepton;
>> > it's a
>> > great library.
>>
>> Thanks, I'm glad you like it!
>>
>> > I'm writing a small game using lepton for explosions. Since there can be
>> > any
>> > number of them at any given time,
>> > I have a simple class that handles adding explosions and then removing
>> > them
>> > once their lifetime has passed.
>> > I noticed, however, that under both Linux and Windows, despite my
>> > explosion
>> > manager not having any references
>> > to the explosions, they were not being freed by the garbage collector.
>> >
>> > I believe that the cyclical references between the ParticleGroups and
>> > their
>> > Renderers to be part of the cause.
>> > Unfortunately, trying to use group.set_renderer(None) results in an
>> > infinite
>> > loop (as the renderer then tries
>> > to call self.group.set_renderer(None) ).
>>
>> Yikes! Though I am happy you discovered this and brought it up. The
>> whole circref between renderer and group is really a vestige of a now
>> outmoded model of how the API was to be used. To "fix" the bug, I have
>> refactored all that magic away. So now, the renderer is simply an
>> attribute of the group and renderer.draw() takes the group as its
>> argument. The renderer no longer holds a reference to the group at
>> all. So although this changes the API of renderer.draw(), it is almost
>> always invoked indirectly from the system or group so it shouldn't
>> pose much of a problem (in fact no examples needed to be changed). The
>> simplification it allows makes it more than worth it IMO. The refactor
>> mostly involved removing code, which is satisfying.
>>
>> I checked in the refactored group and renderer code in r150. Please
>> check out the latest code from svn and give it a try. I will be making
>> a release soon, including some other new features (mostly new
>> domains), but it would be very helpful to have others test this change
>> beforehand.
>>
>> Regardless of the bug, I think you will get better performance by not
>> creating and destroying groups for each explosion. Instead, create
>> groups (perhaps as class attributes of your explosion class) for each
>> kind of particle you use for the explosion effect. When you
>> instantiate a new explosion, emit particles into the existing groups
>> in the class instead of creating new groups. You can use a lifetime
>> controller to ensure the particles are destroyed at the proper time.
>> This will benefit you in two ways: First, it means far less memory
>> allocation going on, which can get expensive. In a steady-state, there
>> should be virtually no memory allocation happening in lepton when
>> groups are used this way. Second, you will be batching the drawing so
>> that fewer state changes (assuming an OpenGL renderer) are required to
>> draw, and less calls will be happening from python. You may find you
>> will need to adjust the blending mode to make this look right, but it
>> should scale much better than instantiating short-lived groups.
>>
>> Thanks for the report and let me know if this change is helpful,
>>
>> -Casey
>
>