Jeremie Courreges-Anglas <j...@wxcvbn.org> writes:
> On Mon, Jan 14 2019, Solene Rapenne <sol...@perso.pw> wrote:
>> Solene Rapenne <sol...@perso.pw> wrote:
>>> Solene Rapenne <sol...@perso.pw> wrote:
>
> [...]
>
>>> I finally found the origin of the issue when loading brutal doom (and some
>>> others mods I hope). When loading assets and making animations, it looks for
>>> duplicates.
>>>
>>> I don't fully understand the logic here, I read that in case of duplicate,
>>> it free the old one and replace it with the current object?
>>>
>>> It's a dirty hack but commenting the free instruction permit to play mods
>>> (having duplicates in their animations I think?) with no noticeable memory
>>> usage change. I added a puts("duplicate") to see if this happens often, it
>>> was like 7 duplicates for brutal doom. As it's only happening at load time,
>>> I would say it's pretty safe to not free this.
>>>
>>> What do you think?
>>>
>>> Index: src/textures/animations.cpp
>>> --- src/textures/animations.cpp.orig
>>> +++ src/textures/animations.cpp
>>> @@ -73,7 +73,7 @@ FAnimDef *FTextureManager::AddAnim (FAnimDef *anim)
>>> if (mAnimations[i]->BasePic == anim->BasePic)
>>> {
>>> // Found one!
>>> - free (mAnimations[i]);
>>> + //free (mAnimations[i]);
>>> mAnimations[i] = anim;
>>> return anim;
>>> }
>>
>> Last version in tarball, including my patch. I've been able to play and did
>> not
>> encounter any issue. From my code reading, it will wastes a few MB of memory
>> if
>> a mod make heavy use of animated textures and have duplicates.
>
> No opinion regarding the workaround.
>
> Looks fine ports-wise except for libexecinfo which should go to
> LIB_DEPENDS instead of BUILD_DEPENDS, and "execinfo" should be added to
> WANTLIB.
>
> With this addressed, ok jca@ to import.Ok, here's new 3.7.2 version with changes added. timo
gzdoom.tar.gz
Description: Binary data
